Tag Info

Hot answers tagged

14

It's explained here Version 1 is read only. Coming up with a solid API is hard enough without adding writing and authentication to the mix. For the initial release, it’s a read-only API. We’ll take on the much more challenging problem of writing (and authentication) in v2.


4

There are two, rather divergent, answers to this question. First and foremost, its not in the API because nobody (us included, woops!) thought of it before the API interface was frozen... so it didn't get implemented, even as a trial feature. Perhaps we'll revisit it for a subsequent version. Alright, onto the real meat of the issue. Headers ...


3

Perhaps I can offer an opinion on cacheability of the API. Please don't downvote before reading through. Caching is hard Caching and cache invalidation is hard. Often, if not always, you need to intimately know the data to be able to cache it effectively. In order to enable a generic Etag caching ability the server will need to execute the request and ...


2

Hmmm. I like this idea, for the record. However, currently we don't track this information. You'll note there's no notion of a user's profile having a history, or an edited date, or anything like that on the sites themselves. Given how far reaching introducing this feature would be, I'm going to [status-deferred] this request. It will be revisited by ...


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


1

Developing this wouldn't be hard, but scaling it would be rough. The problem isn't bandwidth or cpu/ram (at least, not directly) but connections. I did some investigation of COMET (aka. Long Polling) approaches (like Twitter does) for V2.0, and didn't come away very confident. Web Hooks would be an alternative, but there are some serious DOS concerns ...


1

Voting data will never be exposed (as a stream anyway) with great accuracy, as its too easy to correlate it with user activity*. Easier streaming of site updates (questions, answers, comments, edits, etc.) is something I'm considering for the next version, though. *Provided some minimum amount of traffic to the site, anonymity is more or less ...


1

Its because post id 74 is an answer, not a question. This was an undiscovered bug in the API back when we froze it, but enough [app]s depend on it that we haven't "fixed" it. Naturally, answers have no titles or tags.


1

Hmmm... this is an interesting problem. Just going off of usage statistics, nearly everybody is grabbing answers as part of /questions/{id} or /questions. This strongly suggests that what use of */answers there is, is largely independent of corresponding question (if I had to guess, I'd say its generally user analytics of some sort). However, one of the ...



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