Tag Info

Hot answers tagged

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

Every response from the API can be cached for up to a minute, so making the same request multiple times in that time-frame typically won't return different results. We make note of this in the throttle documentation: While not strictly a throttle, the Stack Exchange employs heavy caching and as such no application should make semantically identical ...


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


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

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

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

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

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


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

Comments have only score. So this way comments,answers and questions can have the same field name. Of course a score and downvote_count would still decrease redundancy. btw. the fact that the API has total_upvotes and total_downvotes makes the fact that you need reputation to see those stats on the normal pages weird. (are there more of these kinds of stuff ...


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

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

It is something of a historical accident that this method returns markdown, however it has become too dangerous to change it. Consider it status-bydesign for 1.0 and 1.1.


1

Notifications typically contain links within their bodies. They're considerably more free-form than inbox_items, in that they're not typically attached to a post. Notifications only even have directly attached posts (at time of writing) in the bounty and edit cases. Note that if there's a post_id present, you can query /posts/{ids} to get a link. ...


1

For the time being, as everything on Stack Auth is "query when needed (which is rarely), cache for a day", the inclusion of rate limit headers is kind of pointless. Basically, if you ever need to check that you aren't hitting your quota... you're probably doing something wrong. There are naturally exceptions, but still in 99% of all cases the headers are ...


1

You should be using min and max here if you want tags that were active in that range. fromdate and todate always apply to creation. https://api.stackexchange.com/2.0/tags?min=1322697600&max=1325116800&order=desc&sort=activity&inname=java&site=stackoverflow returns {"items": [{"name":"java-2d", "count":241, ...


1

Suggested buffer size is just a suggestion, you've always been required to handle larger values should they be encountered. Exactly how you do so is an [app] specific detail. In this case, the field backing about_me on the server has been resized since the API was released. It makes about_me a more acute case, but its always been possible to craft a ...


1

As Dennis pointed out, there is no owner (effectively) on that question. That the API does not return a displayable "no user" string in these (and related) cases is an acknowledge deficiency which will be rectified in a subsequent version.


1

StackOverflow Meta is different for the other Metas. This is one of the reasons that meta status is indicated with state and not just the site_url. Valid states are: normal - a full member of the StackExchange network open_beta - a site, open to the public, who's continued existence depends on encouraging performance during the beta period closed_beta - ...


1

No it doesn't. For that matter, I don't recall /questions ever taking nottagged. The API just doesn't reject URLs with extraneous parameters. http://api.stackoverflow.com/1.0/stats?unicorns=yes+please


1

There's a distinction to be made between fields that are empty and those with a default value. score, for instance, is by default 0. It always has a value, conceptually anyway, so it is never omitted. accepted_answer_id is empty by default. Thus it is not returned, rather than filled with a 0 or -1 or whatever. I'd also point out that its basically ...


1

A 406 response breaks* a ton of proxies. In effect, if we strictly follow the standard we prevent many people on corporate networks from accessing the API. We found this out the hard way. *Technically these proxies strip out Accept-Encoding causing a 406 to always occur.


1

Here's Jeff's answer to a question that hasn't been deleted. These users don't actually have names; we're synthesizing a fake name based on their OpenID string.


1

From Jeff's answer to the deleted question* linked to from the question you link to: Your name is inferred from your openid until you specify a display name. You have no display name specified. Thus your inferred username is ... ~quack ... because it's based on your openid URL. It's not an actual, valid display name. If you check ...


1

Checking the reputation rights list it seems that the reduced advertising (well, technically the API could have put ad links into the result) is the only thing besides the updown count where the API is "better".


1

If you set body to false in the request, body on all the responses (two different fields of two different types in two different contexts with the same name... makes it hard to discuss...) is not set. Basically, body is an optionally returned field.


1

I believe the sort=votes parameter is for when you are retrieving multiple questions in one API call, such as with this URL - the questions in the response are ordered by vote. http://api.stackoverflow.com/0.8/questions/1429951;2383701;619895?sort=votes&type=jsontext In terms of how you could sort the responses - you do have the up + the down vote ...


1

I think you misunderstand how request limiting is meant to function. An IP has a limit of requests per-day. By using a key in a request, an application can promote an IP to a higher request limit. Once an IP is at that higher request limit it stays there until the end of the day. At no point is an application drawing from a quota it owns (even paired ...



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