Hot answers tagged

5

For analyzing large chunks of data, don't use the API. Use the Stack Exchange Data Explorer (SEDE), that's what it's there for. SEDE data lags real-time by 1 to 5 weeks, but that's no big problem for most statistical purposes. For intense "Big data" analysis beyond even SEDE's capabilities, use the quarterly data dumps. (Thanks, Tim Stone, for the reminder....


3

I have found that the uniformity of having all of the methods return arrays has made writing a library much easier. Of course if it is a call (like the stats method) which always returns just one result, you don't have to expose it as a list to the API consumer. I don't have any experience with code generation and web APIs so I can't speak to that.


2

Symmetry mostly. Every other method returns a collection, why should /stats be a one off?


2

Its not a high priority, so it may never be back ported to v1. Its highly likely that some version of the API will report those numbers though.


2

/questions?sort=votes and /questions/tagged/{tags}?sort=votes


1

You can get this data easily by scraping or by using the websocket interface that Stack Exchange helpfully leaves available. If you are making an application or webpage, just fetch stackoverflow.com/10m via your app-language's standard fetch/scrape utilities. EG: cURL if you are using PHP, etc. For client side applications, make a Greasemonkey/...


1

Well, the response has been underwhelming so far, but fortunately the powers that be decided to restore the voting tab on the profile page: http://meta.stackoverflow.com/a/130380/182796 So a client-side extension is no longer required.


1

This has been fixed, as of the last deploy.


1

This will be fixed in the next build, we were returning total API stats instead of per-app stats. Silly oversight.



Only top voted, non community-wiki answers of a minimum length are eligible