[tannhaeuser]

What matters is HATEOAS, arguably the starting principle for REST. The whole point of it is that you can follow URLs as links to reach new app states, and discover these dynamically from a page/resource. As in loosely coupled: it's not agreed up-front or out-of-band what's in an URL. What's being practiced instead almost always is that RESTful apps flaunt their "pretty URLs", and advertise these as "API" (making it two wrongs, since it's neither an API nor REST). Squeezing message payloads into URLs only is worth it if you're actually using these URLs in a hypertext context; as a general RPC encoding mechanism URLs make zero engineering sense (have no types, are needlessly/comically limited in capabilities, etc) when your only consumers/producers are programmatic services and clients anyway. What hurts is that so many RESTful apps are using "patterns" dogmatically and in a cargo-cult way, when to me they're just demonstrating they haven't understood the whole concept at all in the first place.

[ivan_gammel]

Pretty URLs do not contradict hypermedia designs. They may leak abstraction, but they can be a convenient implementation detail, decoupling access management and routing from processing the request.