[sashthebash]

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]

Why 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]

There's really no need to create a separate URL; it's reasonable for POST requests to contain response bodies.

[bct]

I 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.