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 ...


7

This is status-bydesign. The site being closed beta prevents people from participating so as to prove that the committers are actually, well, committed. Being able to read data out doesn't allow participation, so we figured why not allow it.


5

This is a bug. The timeline path seems to have several problems. More on these below. The earlier date query returns the result you expect, but look at it in the document explorer: Notice that the entry is a comment and that it has an Owning post. Now if we look at the whole timeline (filtering out some user cruft), we see: Just two revision entries ...


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

No, this is expected behavior, Meta Stack Overflow is indeed a special case - see the original Per-Site Metas announcement, specifically the last paragraph: For now we are leaving meta.stackoverflow.com grandfathered in, as-is, with no changes; it’s still a standalone community with a standalone reputation system. We think Stack Overflow is ...


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

Question and answer data is almost instantaneous. I regularly see Questions with soapi-notify that are 7 seconds old. Answers take a few more seconds. Votes and acceptance sometimes take 30 seconds to a minute to register. Hard to be exact unless I am polling at a rate that may draw unwanted attention. So yeah, there is some latency but nothing more than ...


3

I see that api/stats is a little ahead of the question count: api: 710,258 site (logged in): 710,250 site: (not logged in): 703,405 This makes sense to me, none of those counts is completely live, I assume they are cached and regenerated only every so often (every 10 minutes?), to reduce server load. If the api and the site front page are not generated at ...


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

There are a great many fields on objects returned by the API that will be omitted if they are not set. The user fields you mentioned. locked_date, bounty_date, etc. on questions and answers a whole slew of user_timeline and post_timeline fields depending on the *_type of each ... and many more. We do this because omitting a field clearly indicates that ...


3

Yeah, just displaying blank string will be great. And also same for accept_rate age location website_url too (may be there is even some more) Note: Personally, I don't have any problem with existence of those field or not though


3

Obviously this would best be answered by the one(s) in charge of the API design, but here is my analysis: The two reputation datasets are shaped quite differently indeed and this does matter in various ways - as such I expect this to be more or less status-bydesign: Dataset shape The reputation audit is composed of individual reputation change events at ...


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

Dates increase as time advances, so 1293861600 (Jan. 1st 2011) is greater than 946706400 (Jan 1st. 2000). Thus, a descending ordering puts the most recent dates first. Because sorting by dates is much more common than by name, ordering is descending by default.


3

I am the author of StackApplet and I can verify that the problem you are experiencing is due to a small bug that has since been fixed but hasn't made its way into the latest build for Windows. I will try to build the Windows installer again later and let you know when that is complete.


3

It's mentioned under the Safety section of the filters documentation that by default all response data can be safely inserted into HTML, which is why the data is pre-escaped in this case. You can try creating an unsafe filter using the unsafe parameter to use if you wish to avoid this conversion.


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

The comments are more or less correct; caching applies to the /events endpoint just like every other method. This is by design for now. We have looked at differing caching policies for /events and /inbox/* routes, as the minute lag on those methods is a bit heavy handed; though we still need to protect ourselves from abusive requests.


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

Technically that's incorrect. The help docs say nothing about the required/optional nature of user and owner, only whether certain of their subfields are required should they be present. This is a gap in our automagic doc generation system which will - eventually - be fixed. When it is, user and owner will be marked "optional."


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

This is [by-design]. /search is already pretty resource intensive, and not returning answers is a conscious effort to reduce its runtime. The answers parameter does not appear in the documentation for /search accordingly.


2

The appearance order of sites in /sites is non-determinant and should not be relied upon. On a personal note, using order of appearance as a grouping seems more complex than simply using a meta. modifier I am certain that you can depend on the api.xxx.com/api.meta.xxx.com pattern and can assemble your grouping or relations. And, no, i am no authority, but ...


2

Confirmed: http://stackauth.com/1.0/users/febfb878-3f6f-4215-9323-46d15d62ac7d/associated Edit: I discovered this affects StackCenter too. Some of my accounts show a funny blue picture because the email_hash isn't being passed along.


2

No, money.stackexchange is the first site seeded with the content of an older, SE 1.0 site. Accordingly, some of the content is "older" than the site itself, as are some of its users. In this case, BasicallyMoney (now redirects to money.stackexchange). There's a meta.money post about it.


2

Confirming weirdness with the /users/{id}/answers route. For example, these two queries yield completely different results, although the second one only has a pagesize and page parameters: http://api.stackoverflow.com/1.0/users/180784/answers http://api.stackoverflow.com/1.0/users/180784/answers?pagesize=10&page=1 I would have expected the first 10 ...



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