Tag Info

Hot answers tagged

11

It could be a proxy between you and the API that is mangling the headers that are being sent and making the request without compression. This is one downside to mandatory compression. It might be nice if there was an https endpoint that could be hit to test these types of issues or even to fall back to. If the point of mandatory compression is to save ...


9

I agree that there needs to be a way to discover API endpoints. Especially with the brave new world of SE 2.0 potentially leading to an ever increasing number of API-ified sites out there. However, there isn't a good place to shove this functionality just yet. Currently, we only have two places it could go: ...


8

This is a tricky one, and I can't really say how it will be solved in the future but we'll have to figure out something. The inability to render questions is kind of a major deficiency (if one that didn't exist until well after 1.0 was frozen). This has been added in 1.1. /1.1/sites reports markdown_extensions with values Prettify, MathJax, and jTab as ...


6

For /sites (and only it) I have removed the pagesize constraint. I believe in this case it makes sense, since applications are expected to query all of that data and cache it for long periods of time. The constraint remains elsewhere, as it's very important for performance reasons.


5

This is important if you want to be able to build an app that supports all available sites. Right now there are only a few, but eventually the list will grow and simply adding entries by hand will become too difficult. There also was a similar request for discovering what versions of the API are available. The tricky part is that the methods would not ...


5

Thanks for this, I like it. The proposal's style is as clean and polished as other state of the art marketplaces; here are some screenshots: Apple Google Microsoft Mozilla On your proposal I would add: Authors: I like what Mozilla does, Author should be displayed. Votes: we don't have number of downloads or shiny stars. Votes number is our rating ...


4

Anything that supports a sort of activity can do this already. ?sort=activity&min={start-date}&max={end-date} Where start-date and end-date are unix timestamps. Update /questions and /questions/unanswered now honor min, max, and order. sort | min and max limit -------------------------------- active | last_activity_date newest | ...


4

We're fixing this, shouldn't be too much longer (may even have been done by the time you read this). Basically, this is another consequence of using a cloud computing service. We've got a bunch of crummy (and technically illegal, due to attribute violations) sites out there that like to scrape us. Now, we realize its a fools errand to try and prevent ...


4

Anything we should be showing and aren't? Attribution (i.e. keep the author name/link) My vote would be to drop the noisy reputation and last update time indeed, but keep the author name/link in the bottom right corner still, albeit with substantially reduced color/contrast (e.g. the last update color currently in use would probably do just fine): ...


4

ASP.NET was freaking out about the < in your search term. Fixed it*. More generally, the API always returns compressed content; so everything is "binary," this case just showed it more obviously due to the unusual error. *It's worth noting that the actual < and > are not indexed by our Lucene search provider, so you can't actually search for ...


4

the original question was apparently for V1. in V2 we now have https://api.stackexchange.com/docs/required-tags the request: https://api.stackexchange.com/2.0/tags/required?order=desc&sort=popular&site=stackapps will return required tags


4

Whelp, that was an oversight. accept_rate should now be returned on both user and shallow_user. Note that when insufficient data is available to calculate an accept rate, we don't return anything at all. The exact rules for calculating accept rate are subject to change, but currently documented here. The API returned accept rate should always match the ...


4

Tricky. This was a consequence of the API misinterpreting a normalized field used elsewhere in the system to indicate whether or not a post has upvoted answers. Everywhere else, "is answered" is true if either of the following are met: The question has an accepted answer The question has an answer with a score > 0 The API wasn't doing the "or" check. ...


3

Adding max=-10 will only show score with -10 or lower questions http://api.stackoverflow.com/0.8/questions?sort=votes&order=asc&max=-10&type=jsontext


3

Eventually, yes. Please see this answer for some more details. The short of it is, there isn't really a good place to shove this kind of data yet. Especially if you're planning for the Count(Sites) > 5 case, which we are. StackAuth implements this feature now.


3

Kevin hinted at something like this when I was discussing making a FUSE (file system in userspace) implementation of the API on dev.meta. It would work like this, assuming you had the file system mounted on /stacks : cat /stacks/stackoverflow.com/users/1/reputation ... You'd see Jeff's reputation. The problem is (and was) is that I'd need to be able to ...


3

No need, the "apps" tag pulls anything tagged "app" or "library" already. Alternately, just click library and browse all the libraries. (sorry, this change has been in for a while, we just hadn't deployed.)


3

Alright, here's what we're going to try. First off, we're not giving hard guarantees as to the maximum length of strings returned. Such a guarantee could create a situation where we might have to release an API revision just to accommodate increased text limits on the trilogy sites, or one - which is equally bad - where the API would return truncated ...


3

They have moved also these favicons (hard-coded in Swatch): http://sstatic.net/sf/favicon.ico http://sstatic.net/su/favicon.ico http://sstatic.net/sa/favicon.ico


3

The API now responds with the following headers: HTTP/1.1 200 OK Server: nginx/0.7.65 Date: Fri, 20 Jan 2012 18:53:44 GMT Content-Type: application/json; charset=utf-8 Connection: keep-alive Cache-Control: private Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, POST Access-Control-Allow-Credentials: false Content-Length: 12345 Since we ...


3

This should be fixed now. Really fun set of bugs there actually. In the API we delegate most tag operations to a couple (conceptually) external services, there was a dodge bit of logic in building the request w.r.t. min/max creation dates. However, fixing that revealed another more pervasive bug around date precision. Most of the API, and the backing ...


3

Found it, fix has been deployed. There was a bit of confusion around loading tag data*, basically trying to get the "required", "mod only", and "sponsored" tags for api.stackexchange.com... which doesn't end well. *Data necessary for rendering revisions that have the [tag:name] markdown extensions.


3

This has been fixed with the latest deploy. There was a bug introduced in our move to elastic search where min/max was applied after paging results, instead of before. This meant that in any question that would typically have a lot of out-of-range results, the first page would tend to be culled down to nothing.


3

Fun one. Changes behind the scenes to how closed reasons are handled caused the API to stop getting a real reason and start getting a null one. This was just different enough from failing to get a reason that it went unnoticed, oy. This was fixed in the most recent build.


3

Update: Per Kevin Montrose's answer and its comments: The bug has now been fixed and the is_answered property will return true if either of these is true: The question has an accepted answer The question has an answer with a score > 0 To detect just whether a question has an accepted answer, merely check that the accepted_answer_id property is present ...


3

We moved from nginx to HAProxy for our SSL provider this weekend as part of a larger rollout. In the move, we shifted our header checks to the now de-facto standard SSL protocol header. While I thought I fixed all the apps relying on the old header and standardized everything internally, stackexchange.com was left out and thought your auth requests weren't ...


2

Returned parameters now have an optional field in the documentation (example) that indicates whether they should always be present. For the duration of the beta at least (not going to guarantee 1.0+, there are some performance implications) we're actually enforcing this. If a response we're to somehow not have a required field set, an error will occur ...


2

We're using number in the JSON sense of the word. number in that context does cover all the data types we're returning. I suppose it could be tightened up a bit, though... Descriptions of the types of number coming back are now part of the /help docs.


2

The way it should be... UsersResult actual = target.GetResult(site); while (actual.Users.Length > 0 ) { target.Parameters.page++; actual = target.GetResult(); } The way it is (as of 10 minutes ago) try { UsersResult actual = target.GetResult(site); while (actual.Users.Length > 0) { target.Parameters.page++; ...


2

Done. Compare: http://api.stackoverflow.com/0.8/errors/4002 and http://api.stackoverflow.com/0.8/errors/4002?jsonp=wrapperFunc



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