What is the motivation for building api.stackoverflow.com in a manner that accepts multiple IDs in a resource call?

For example, I can use /questions/123/ to return the question record number 123, or I can use questions/123;124/ to simultaneously return question record numbers 123 and 124.

I like the concept, because it allows me to mimic the functionality of a query like SELECT * FROM SOME TABLE WHERE ID IN (123, 124);. But I would like to know what specific functionality or requirement a vectorized call fulfills.

I'm having a difficult time imagining a use for a vectorized call that cannot be fulfilled by a /questions? call.

2 Answers
2

The most immediate use is to facilitate polling on a set of resources.

How you get that set is pretty much wide open:

user's can enter them (questions, answers, other users, whatever)

you can discover them through a different query

some combination of the two

randomly

Once you have them, you'd rather not have to replicate the query. It's slower, wasteful of request quota, and sometimes impossible (in the cases where the results of the original query can easily change, like anything based on last_activity_date).

It's much better to just find all the relevant ids once, and then poll. And since each poll eats a request from an app user's quota, you'd rather get as much bang for your poll as possible.

Related, it makes it much easier to streamline requests. If you've got a big list of ids you can fetch all the data in (num_ids / 100) requests, which can be decidedly faster than doing them 1 at a time (mostly because of round trip time, but there are some benefits internally too).