Tag Info

Hot answers tagged

10

There wouldn't be a lot of code re-use between the SE API (.NET), OSQA (Python) and Shapado (Rails). If others want to, they can implement a compatible API without any of the server-side code. In fact, that's one of the biggest selling points of this type of API, it uses standards like HTTP and JSON that you can produce with any web framework. With a ...


7

I guarantee that if we did this, a large chunk of the developed apps would rely on /latest and break horrendously every time we rev'ed the API. The end user experience would be bad, developers would be frustrated (as their code literally just stopped working one afternoon), and we'd have to deal with a bunch of erroneous bug reports ("/some/method stopped ...


6

This is definitely private and should not be exposed by a read-only API that does not authenticate for that user.


6

Beta is an unusual time, in that the version number changes fairly frequently. Once we're into 1.0, such changes will basically never happen. You'll always be in 1.0, unless you explicitly target a newer version of the API; which will probably be rife with breaking changes, requiring much more than a recompile. As such, no discovery mechanism for API ...


6

For now, as we have only ~80 sites, you can set pagesize to 100 and get them all. But in general, I think pagination here makes no sense at all. Because there're no search parameters or ordering, I can't think of a situation where app can fetch only first page and be satisfied. Would it be possible to provide a way to search the list instead? I would ...


5

No. Its far too late in the v1 game to add something this complex. Note that the current policy is that you shouldn't be polling faster than once a minute, not two minutes.


5

Here it is! SVG version here Note: the same restrictions on this trademarked icon that apply here, also apply to the icon above.


4

bump I've just delved into the stackauth methods for the first time today, and I can't help but notice that there's no real URL friendly key exposed. For example, I want a unique URL for each API endpoint in my app, so that it can be bookmarked. E.g. http://www.column80.com/?site=stackoverflow But none of the keys provided are any good. name has spaces ...


4

This is private per-user information. Accordingly we can't expose it until some sort of user auth is in place, which isn't a v1 target.


4

Everything you want here is already implemented, except for next_downtime, which requires a level prescience we don't yet possess. API version is already served by the /stats method. Quota information is found in the X-RateLimit-Current & X-RateLimit-Max response headers.


4

I'm declining this, not because I don't see the merit in it, but because we don't have the data to return in anything approaching a reasonable time. Our badge awarding code is very complex, and intentionally run in staggered (and even, in some cases, random) schedule to prevent DOS-ing our own databases. Opening those queries up via an API would be ...


3

The SO engine isn't getting open sourced in the foreseeable future. The API is part of the engine, so it isn't either. That being said, we do make all of the data "open-source" (cc-wiki, but close enough), there's MarkDownSharp, and some more stuff coming down the pipeline. API specifically, all the external bits of our test suite are part of The World's ...


3

No. E-mail hash is a pretty terrible way to determine account association, as there's no uniqueness guarantee. I touched on why account associations - which is a more general case of what you're asking for - aren't exposed in this answer, but I'll copy it here too. Currently, we only have two places it could go: ...


2

Normally, I am the one arguing for more data but in this case I will anticipate (and agree with) Kevin's likely response: The tag meta is not relevant to a question and inclusion of tag meta would be a significant increase in response data as well as requiring an additional join into the tag table increasing the execution cost of generating the response. ...


2

The problem with this isn't so much the security (though that's a concern), it's that we don't want the backwards compatibility constraints such blessed installations imply on our HTML and javascript. As such we're unlikely to ever do something like this, so I'm status-declined-ing it.


2

Actually, your browser does not download images on every request but perform a conditional request to the server using the If-Modified-Since header. In case the image is not changed, the web server returns a 304 Not Modified status telling the client "resource you are requesting is not modified, use your cache :)".


2

No, we still want people looking at updated app listings for vandalism and the like. Plus I dislike the idea of having the active tab differ in meaning only on StackApps. There's still something to be said for commonalities between the Stack Exchange network sites.


2

If you're persisting data, the omission of the site is enough of a signal that its been removed (for whatever reason). Keep old sites around indefinitely is just polluting /sites, and removing them after some fixed time period means any consumers have to deal with their eventual removal anyway. Might as well just remove them and be done with it.


2

Careers does not and will not expose the SE API. Thus it won't be listed in StackAuth.


2

BUMP: Although this request seems sealed with a status-declined flag.. i started to play with Stackauth and i have to say that what requested in this post is more than proper and reasonable. Using /sites i had to craft an utility method that strips the domains from site_urls using regex (^http://(.*).com$ ), adding them to the data structure as keys. ...


2

Actually, this was answered in your previous question :) some private things do go into the inbox. They are quite rare, but they're there. Personally, I've never seen any of those 'private things', but I'm not user 1 either. Do admins use it to send ponies to each other?


2

No, we won't be implementing this. Not that I don't see a use case for it, but we'd never be able to accept and execute arbitrary regular expressions against the database. It'd just be far too easy cripple performance wise (we've done this accidentally plenty of times, and we don't have to worry about malicious actors on the dev team). While we could ...


2

Just like they cloned the format and concept, they can clone the API. It's self-documenting and available for testing. There would be no gain in open-sourcing the server-sided layer of it, and documenting a 'protocol' would be too constraining and involve too much effort. I say it's fine just the way it is.


2

If you are thinking about creating a full fledged application that could be open to users, I highly suggest against using a latest version API call. This is because even though you want to keep up with the latest version, it would be horrible for your application to break, and your users to have to wait until you dealt with the changes to the API to be able ...


2

It would make more sense - in my opinion - for a library to abstract the paged nature of results away entirely. Furthermore, there's no need for the objects exposed by whatever deserialization code to reflect the naming scheme of the underlying JSON. If you want more automatic code, you could just define the data field as not total, page, or pagesize. The ...


2

Categories aren't sufficiently stable to expose in the API. It is entirely possible (even likely, in my opinion) that we'll revisit and rework the proposal categorization significantly in the coming year.


2

You can implement this yourself pretty easily. A random date range, with todate & fromdate on /questions, will work fine. Basically, pick a random question (via page) from a random hour/day/week/month/whatever.


1

Perhaps a good approach would be to cache the entire list of tags on a site (there are only 770, or 25 pages worth on Travel.SE). You can then run them through a RegEx locally. Tags don't change very much so you could just refresh your list every week or so to keep it up to date. You didn't specify a particular language / framework, but if you were using ...


1

Chat notices from private rooms (mostly available to moderators) and careers messages go into the inbox. These things are private, and will not be exposed prior to authentication. I'm declining this as a request for authentication-less inbox access.


1

Pagination on /sites is solely so [app]s don't have to pull down any unknown, large, and constantly growing chunk of a data in a single request. It is expected that every consumer would grab all sites in a series of sequential (or concurrent, if they're comfortable with that) requests for each page.



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