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.


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


9

I agree that there needs to be a way to discover API endpoints. Especially with the brave new world of SE 2.0 potentially leading to an ever increasing number of API-ified sites out there. However, there isn't a good place to shove this functionality just yet. Currently, we only have two places it could go: ...


8

No we don't. It is an app. Simplicity is key to keep clutter at a minimum. The current two categorizations are perfect: An app is something you make that utilizes the API to do something. A library is something that provides an abstraction between an app and the API. No need to invent a bunch of categorizations that aren't necessary.


8

This is a tricky one, and I can't really say how it will be solved in the future but we'll have to figure out something. The inability to render questions is kind of a major deficiency (if one that didn't exist until well after 1.0 was frozen). This has been added in 1.1. /1.1/sites reports markdown_extensions with values Prettify, MathJax, and jTab as ...


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

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

They have been very clear that version 1 of the API will be read only and they will be revisiting the POST type features (like adding new questions and answers) for the next version of the API. You can post and vote for the features you would like to see in the next version here. You can also view any feature requests which have been deferred to some future ...


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


6

For /sites (and only it) I have removed the pagesize constraint. I believe in this case it makes sense, since applications are expected to query all of that data and cache it for long periods of time. The constraint remains elsewhere, as it's very important for performance reasons.


5

This is important if you want to be able to build an app that supports all available sites. Right now there are only a few, but eventually the list will grow and simply adding entries by hand will become too difficult. There also was a similar request for discovering what versions of the API are available. The tricky part is that the methods would not ...


5

Currently there is only one version alive at a time (0.8). While in beta, I'm guessing this will be the norm. Once out of beta, there will probably be an upgrade period for minor versions ("1.1 is released! Update your 1.0 apps!"). However, for major versions there will be two api's running at the same time (1.0 and 2.0). From the original API ...


5

It is supposed to include answers (probably first page only), and documented (look for "answers" in return json), but there was a bug, and it has been fixed recently. But yes, I also think answer=true option would be nice.


5

I believe that's a correct approach. There's a way to optimize it saving one request but it's a little bit unsafe for this bug: call /questions/{id}; If you get a result with a title parameter it's a question If you get a result without a title parameter it's an answer, thus you should call /answers/{id} for the title EDIT: I've just realized that ...


5

I don't see any particular reason not to add it, but there are some workarounds you can use in the meantime: Build a cache of all site information with the site URL as the key, and then look up the api_site_parameter value (and associated information) that way. or Use the fact that the domain name can be passed in as the value for site, and clean up ...


4

Anything that supports a sort of activity can do this already. ?sort=activity&min={start-date}&max={end-date} Where start-date and end-date are unix timestamps. Update /questions and /questions/unanswered now honor min, max, and order. sort | min and max limit -------------------------------- active | last_activity_date newest | ...


4

Totally agree with this. (In fact, I would love to see the mobile site become a subdomain of StackOverflow.com!) There should be some sort of criterion for this, such as: The application should have at least x votes (maybe 10?) The application should have been in use for at least x days (maybe 14?) I like the idea of redirects - that way SO doesn't have ...


4

First of all, I completely agree with Joel Potter's answer. However, here, I want to respond to the feature-request part of your question. I think that the Team needs to implement a small feature here on StackApps that was present during the private beta. I'm referring to a small banner at the top of each page here (the ones that are usually used on ...


4

Actually, I think I figured out a way to do this. If you specify the following: /users?filter=john&sort=name&min=john&max=JOHN That is, sort by name with "min" and "max" both set to "john" then it returns only those people whose name is exactly John. I wonder whether this efficient for the backend to process? It seems to respond pretty ...


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

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 original question was apparently for V1. in V2 we now have https://api.stackexchange.com/docs/required-tags the request: https://api.stackexchange.com/2.0/tags/required?order=desc&sort=popular&site=stackapps will return required tags


4

If you have a valid session cookie for a given user, you actually do have access to the messages in the Stack Exchange dropdown using the following URL: http://stackexchange.com/genuwine This URL returns the user's most recent notifications across the network as JSON data. Keep in mind that this would only be useful in a situation where you have access to ...


4

Whelp, that was an oversight. accept_rate should now be returned on both user and shallow_user. Note that when insufficient data is available to calculate an accept rate, we don't return anything at all. The exact rules for calculating accept rate are subject to change, but currently documented here. The API returned accept rate should always match the ...


4

There are 2 ways to get the 10 most recent questions of a tag, either on the /questions method or /search method. The parameters on both routes are the same, just set tagged to your tag (eg iphone), and sort to creation, and order to desc So that's either: ...


4

I don't follow, for date times the most recent date is the largest date. Sample return by events { "event_type": "question_posted", "event_id": 9369546, "creation_date": 1329777738 }, { "event_type": "comment_posted", "event_id": 11832402, "creation_date": 1329777736 } 1329777738 => Mon, 20 Feb 2012 22:42:18 GMT 1329777736 => Mon, 20 Feb 2012 ...


3

Alright, here's what we're going to try. First off, we're not giving hard guarantees as to the maximum length of strings returned. Such a guarantee could create a situation where we might have to release an API revision just to accommodate increased text limits on the trilogy sites, or one - which is equally bad - where the API would return truncated ...


3

The sandbox that @George Edison was referring to was formating sandbox. I started a new API sandbox at: http://meta.stackoverflow.com/questions/51812/the-api-sandbox which should be free to post any test answers and comments.


3

As a result of direct contact by yours truly with the SO team, the thresholds for CW were relaxed for app/library posts on StackApps a few weeks ago. I will defer to the powers that be to post the specific numbers if/when they deem appropriate, but I can confirm that they are significantly increased from previous values. Don't go nuts churning your posts ...


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



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