7 ms·
I almost completely agree, but a problem I often encounter in REST API design is: how to do searches? Let's say we have an "Event" Resource and it belongs to a
by sashthebash 15y ago
I almost completely agree, but a problem I often encounter in REST API design is: how to do searches?
Let's say we have an "Event" Resource and it belongs to a "Location" Resource and the Event belongs to "Category" Resources. If you want to provide an endpoint to search events with a GET requests and filter based on Location and Categories (which are identified by URLs) you can end up with really long query strings.
/events?location=URL1&categories[]=URL2&categories[]=URL3&categories[]=URL4&...
This is not only ugly, it can bring up problems on both clients and servers.
Any suggestions on how to handle this?
- icebraining 15y agoWhy use GET instead of POST? Just POST a document with the parameters to filter, and the server creates a new resource with the search results and returns its URL to the client, which can then GET it.
- boucher 15y agoThere's really no need to create a separate URL; it's reasonable for POST requests to contain response bodies.
- bct 15y agoI don't think there's anything particularly unRESTful about using non-URL ids in that case. The critical thing is that the client isn't using out-of-band knowledge (i.e. what the developer read in the API documentation and hardcoded into the client) to construct the query.