Tag Info

Hot answers tagged

5

There is no tutorial for the API, nor is there likely to be one -- at least officially. There is a "Hello World" introduction. To use the current API (version 2.1), you really only need to know/do: How to make an HTTP GET request, in the language of your choice. There are also various user-supplied libraries in .net, PHP, Python, etc. to help with this. ...


4

According to this answer, it looks like 100.


4

That is the 2.1 documentation, it's just the title (and perhaps the first sentence) that hasn't been updated. All of the routes added in 2.1 are there, so you don't have to worry that it's missing anything important.


4

This is currently not possible via the API. The best you could do is have the user logged into a browser and then screen-scrape the stackoverflow.com/users/{user_id}/?tab=votes pages... Hardly an acceptable workaround. The Authentication doc, Scope section, does say: private_info - access full history of a user's private actions on the site. ...


3

Well technically it already says "Most methods" so it's correct as written. But I agree, it's easy to miss that note. After the next build there will be another sentence mentioning that some methods have lower limits and their individual documentation pages will call them out (as they already do). Should be harder to miss that way.


3

The console JS was doing fuzzy matching on ?site; but that's not really correct, as you demonstrated. With the latest deploy it does an exact match if possible.


3

Are they moved to filters? Yes, you need to generate a filter that includes the question.body, question.comments, and question.answers fields. There are shorthand filters (i.e. _bca) that will do this for upgrade compatibility, but their use is discouraged and you're better off just making a filter that contains exactly what you want anyway.


2

body and comments have been removed from those methods.


2

Looks correct to me.


2

Methods now return only a single result for a given id, even if that id is found multiple times in the passed {id} field.


2

We're using number in the JSON sense of the word. number in that context does cover all the data types we're returning. I suppose it could be tightened up a bit, though... Descriptions of the types of number coming back are now part of the /help docs.


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

Returned parameters now have an optional field in the documentation (example) that indicates whether they should always be present. For the duration of the beta at least (not going to guarantee 1.0+, there are some performance implications) we're actually enforcing this. If a response we're to somehow not have a required field set, an error will occur ...


2

Commercial use of the API is permitted. If you're just displaying content on a website, you should follow our attribution requirements. If you have questions about a more specific use case, feel free to contact us.


2

This has been fixed. Going to a particular API/usage page should run requests against that API, instead of the default demonstration site (which has always been SO).


2

Annoyingly all usuage pages on all sites use the stackoverflow api site. I think Kevin said this is because changes to the API happen first on stackoverflow. (not sure why this is a problem, because the API hardly ever changes)


2

Take a look at http://api.stackoverflow.com/1.1/usage/enumerations ; which is now linked from the front page of the documentation as well. Its very simplistic, but one of the nice behind the scenes changes in 1.1 was making it a lot easier for me to update the documentation. Expect some better documentation on returned values in the not incredibly distance ...


2

The documentation was confusing there, event_id is the question/answer/etc. id. I've modified the documentation for the event type.


2

inname has been documented on /users and /tags now. Thanks for catching that oversight.


2

Quoting the very first paragraph in the section General: Applications should be registered on Stack Apps to get a request key. Request keys grant more requests per day, and are necessary for using access_tokens created via authentication. Click the first link, and there's the registration form.


2

A fix for this will go out in the next build.


2

key is your app key, access_token identifies a user (and a set of permissions) and is what you get at the end of an authentication flow. Keys are not secret, for example here's what the Documentation Console's registration looks like: You can find your app key by going to Manage Your Applications (in the Stack Apps homepage sidebar) and selecting one of ...


2

This is just the reputation that the user has earned for the given period (day/week/month/quarter/year). For example, for you, for Stack Overflow, the API currently returns: "reputation_change_day": 0, "reputation_change_week": 0, "reputation_change_month": 32, "reputation_change_quarter": 63, "reputation_change_year": 111, This should jibe with what ...


2

This was fixed in the latest deploy.


1

A fix for this will go out with the next build.


1

This, and a few other documentation typos and errors, was fixed in the latest deploy.


1

This will be fixed in the next deploy.


1

inname limits the returned items to only those that contain the specified value. This parameter is identical to the filter parameter in v1.0 and v1.1 of the API. Note: this parameter is also present in the /users route.


1

The next build will push a correction to the auth documentation.


1

This has been fixed in the latest deploy.



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