{"action":"created","issue":{"url":"https://api.github.com/repos/18F/open-data-maker/issues/63","labels_url":"https://api.github.com/repos/18F/open-data-maker/issues/63/labels{/name}","comments_url":"https://api.github.com/repos/18F/open-data-maker/issues/63/comments","events_url":"https://api.github.com/repos/18F/open-data-maker/issues/63/events","html_url":"https://github.com/18F/open-data-maker/issues/63","id":95548919,"number":63,"title":"As a data consumer, I would like to get aggregate statistics about the entire data set so that I can make more informed comparisons","user":{"login":"shawnbot","id":113896,"avatar_url":"https://avatars.githubusercontent.com/u/113896?v=3","gravatar_id":"","url":"https://api.github.com/users/shawnbot","html_url":"https://github.com/shawnbot","followers_url":"https://api.github.com/users/shawnbot/followers","following_url":"https://api.github.com/users/shawnbot/following{/other_user}","gists_url":"https://api.github.com/users/shawnbot/gists{/gist_id}","starred_url":"https://api.github.com/users/shawnbot/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/shawnbot/subscriptions","organizations_url":"https://api.github.com/users/shawnbot/orgs","repos_url":"https://api.github.com/users/shawnbot/repos","events_url":"https://api.github.com/users/shawnbot/events{/privacy}","received_events_url":"https://api.github.com/users/shawnbot/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/18F/open-data-maker/labels/help%20wanted","name":"help wanted","color":"159818"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-07-16T23:01:31Z","updated_at":"2015-08-11T05:00:28Z","closed_at":null,"body":"One need that we have for the Ed project is to get aggregate statistics, e.g. the median graduation rate for all schools. I'm imagining an API endpoint that you could access like so:\r\n\r\n```\r\n/:endpoint/stats?fields=graduation_rate\r\n```\r\n\r\nWhen you need more than one field or statistic, as we will in our project, you could just comma-separate them:\r\n\r\n```\r\n/:endpoint/stats?fields=graduation_rate,net_cost\r\n```"},"comment":{"url":"https://api.github.com/repos/18F/open-data-maker/issues/comments/129706756","html_url":"https://github.com/18F/open-data-maker/issues/63#issuecomment-129706756","issue_url":"https://api.github.com/repos/18F/open-data-maker/issues/63","id":129706756,"user":{"login":"siruguri","id":40653,"avatar_url":"https://avatars.githubusercontent.com/u/40653?v=3","gravatar_id":"","url":"https://api.github.com/users/siruguri","html_url":"https://github.com/siruguri","followers_url":"https://api.github.com/users/siruguri/followers","following_url":"https://api.github.com/users/siruguri/following{/other_user}","gists_url":"https://api.github.com/users/siruguri/gists{/gist_id}","starred_url":"https://api.github.com/users/siruguri/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/siruguri/subscriptions","organizations_url":"https://api.github.com/users/siruguri/orgs","repos_url":"https://api.github.com/users/siruguri/repos","events_url":"https://api.github.com/users/siruguri/events{/privacy}","received_events_url":"https://api.github.com/users/siruguri/received_events","type":"User","site_admin":false},"created_at":"2015-08-11T05:00:28Z","updated_at":"2015-08-11T05:00:28Z","body":"I take it that you would like to be able to do stats on subsets of the index, so it'd be nice to retain the search call syntax and somehow extend it to include stats.\r\n\r\nI didn't want to code hastily before thinking through the design a bit. There seem to be two approaches - have all possible new endpoints by default behave like search, with additional parameters specific to that endpoint, OR have only one endpoint per index as you have it currently but have a namespaced set of arguments in the Rails format that essentially act like you had an advanced search interface with dropdowns/checkboxes etc.\r\n\r\nThe former makes for simpler parameter structure, but seems to have various problems with extensibility - for one, it means that each endpoint will have its own reserved keywords, progressively constraining index column names; and two, composing multiple actions will be hard.\r\n\r\nSo in this case, the examples would look like (for all cities in Texas):\r\n\r\n1. `/cities/stats?state=TX&fields=land_area,population&metric=avg`\r\n1. `/cities?state=TX&postprocess_command[name]=stats&postprocess_command[args][fields][]=land_area&postprocess_command[args][fields][]=population&postprocess_command[args][metric]=avg`\r\n\r\nA non-routes based option is to have a POST body with a query language of some sort in the body.\r\n\r\nThoughts?\r\n"}}