Question

All the examples I’ve seen regarding a RESTful architecture have dealt with a single record. For example, a GET request to mydomain.com/foo/53 to get foo 53 or a POST to mydomain.com/foo to create a new Foo.

But what about multiple records? Being able to request a series of Foos by id or post an array of new Foos generally would be more efficient with a single API request rather than dozens of individual requests. Would you “overload” mydomain.com/foo to handle requests for both a single or multiple records? Or would you add a mydomain.com/foo-multiple to handle plural POSTs and GETs?

I’m designing a system that may potentially need to get many records at once (something akin to mydomain.com/foo/53,54,66,86,87) But since I haven’t seen any examples of this, I’m wondering if there’s something I’m just not getting about a RESTful architecture that makes this approach “wrong”.

Answer 1

While I don’t see anything intrinsically wrong with your approach, it seems a little odd for a user of your API to want foo records with arbitrary IDs. I’d immediately suspect that they are using the IDs to represent a different concept, e.g., all the foos that were created in the last week, etc. If that’s what they’re doing, then you should probably expose that functionality on the server instead of using the list of IDs as a surrogate.