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