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


4

The inbox does not use the API. It can't be exposed until a subsequent version when user authentication is supported.


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


2

Why do you need the JSON representation of the help? For what purpose? Regardless of what we said, why would that be useful?


2

Markdown won't be coming until write access, which is slated for a later version of the API.


2

Its not a high priority, so it may never be back ported to v1. Its highly likely that some version of the API will report those numbers though.


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


1

All write access is deferred until a future release, V2.0 is just adding authentication (and more read-only stuff, naturally).


1

Reputation history with perfect accuracy isn't something we actually have a fast way to generate at the moment. There is some work under way to make such information available for other purposes, it will probably be exposed as part of a future API revision.


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

Its too early to call this, as the chat system is still evolving. However, exposing the inbox is planned and since some chat events are published to the inbox there will be at least some exposure of chat events.


1

Never mind markdown. Some of my apps just need plain text.


1

I imagine that once write-access is supported, presumably in version 2.0, they'll have to return the markdown source along with the generated HTML.


1

I'm not convinced this is needed, nor does it immediately strike me as a bad idea. So I'm taking the easy way out and putting it on the "consider for subsequent versions" list.



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