5

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 both items and total 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

3
  • 2
    lol the docs really do have loads of typos! :P and yeah, those other words are typos it seems. May 19, 2016 at 16:31
  • @α”•α–Ία˜Žα•Š : Even I looked only this Documentation page and the links form that pages only (not on side bar links). If you cross-check on other pages, it will be more.
    – Arulkumar
    May 19, 2016 at 17:53
  • 2
    Looks like someone fixed programatically => programmatically on users-by-ids, but the rest of these are still there.
    – 3D1T0R
    Jul 29, 2018 at 20:38

1 Answer 1

2

The fixes for this were just pushed in the latest build. Thanks for reporting it.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .