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

v1 of the API lacks user auth, so such restrictions are unenforceable. We'd have to deny it to everyone (and arguably, a large percentage of the end-users of the API are going to be over that rep limit) which, to me, would be kind of overkill.


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

There is a pretty good chance the Jon has hit the cap today. So he only got rep for the accept. The data is real time, so it is actually cached less than the website.


4

Note that Meta Stack Overflow is, and has always been, Meta Stack Overflow. not Stack Overflow Meta. Thus, these members of the trilogy inherit that naming choice.


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

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

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

These are around because of popular demand in the private beta. I have mixed feelings about them, honestly. However, I'd rather not remove anything this late in the beta.


3

Question titles aren't markdown, they're plain text. Accordingly, if you're going to display them in HTML you shouldn't display them "raw".


3

Take a look at the answers parameter. Docs


3

The question counts on the site are cached. They don't update realtime, so they will always be behind live numbers


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

There is "accepted_answer_id" for questions method. When there is no accepted answers,that field does not exists in returned JSON. So hasAccepted is the existance of "accepted_answer_id" field.


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

I would assume the answer is Yes. Although Meta Stack Overflow is a Meta site, it is also the "capital" for the Stack Exchange engine as a whole, and unlike all the other Meta's also has individual reputation per user. It is really a special Meta site.


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

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

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.


2

There are lots more. The problem is that having something blank doesn't convey that the user hasn't filled it in... just that it's blank. I think it should stay the way it is.


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

Actually, there is timeline for any users, that can see up/down votes as well. http://stackapps.com/posts/551/timeline


2

See http://stackapps.com/questions/725/supported-platforms gzip is being enforced with predjudice.


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

Answers changed to be off by default: http://stackapps.com/questions/613/dont-include-answers-in-question-lists-by-default


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

This is because the user hasn't specified a username on those sites yet. The name you see on SuperUser, for example, is somehow derived from his/her OpenID.


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

The domain name is up for debate right now. Who knows whats going to happen


2

Meta.StackOverflow is a meta in name only. It is not Stack Overflow's meta, at least not from the API's perspective. Its a tad confusing, I know. Its a consequence of the "per-site meta" concept being introduced long after meta.SO existed.



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