https://api.stackexchange.com/docs/vectors
When passing a vector, sepeate each id with a semicolon. For example, /users/1;2;3;4;5?site=somesite would fetch users with ids 1 through 5 on somesite.
sepeate => separate
https://api.stackexchange.com/docs/min-max
Another handy trick is to only request the total field when all you care about is the quanity of items meeting some criteria, such as when calculating statistics. The
?filter=total
built-in filter is provided for just this purpose.
quanity => quantity
https://api.stackexchange.com/docs/wrapper
The
error_*
fields, while technically elligible for filtering, will not actually be excluded in an error case. This is by design.
elligible => eligible
https://api.stackexchange.com/docs/paging
total
is also a useful property when displaying paging controls. In this case applications would want to include bothitems
andtotal
on a filter rather than making two seperate requests.
seperate => separate
https://api.stackexchange.com/docs/compression
While effectively all browsers will always request compressed content, many (if not all) of the applications using our API will be on decidely less mature HTTP stacks. The likelihood of many applications not opting into compression, and being materially worse for it, is unacceptable.
decidely => decidedly
Few other words, not sure they are typos:
https://api.stackexchange.com/docs/wrapper
When building filters, this common wrapper object has no name. Refer to it with a leading ., so the items field would be refered to via .items.
refered => referred
https://api.stackexchange.com/docs/filters
The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time ...
unneccessary => unnecessary
https://api.stackexchange.com/docs/users-by-ids
{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for user_id on user or shallow_user objects.
programatically => programmatically
programatically => programmatically
on users-by-ids, but the rest of these are still there.