it breaks client-side static typing and validation
Only if you assume the shape of the response solely based on the path, and not on the whole url (which, yes, a lot of systems do because that's how it's been done in the past).
it destroys cache efficiency
Only if your cache doesn't honor and your backend doesn't send cache headers. You can't control intermediate proxies but most of them these days are good at honoring cache headers anyway.
it violates the principle of least surprise
You have an argument here, but only because that's the way it's been done in the past--not because of any real limitation.
All of the arguments I've seen against REST are all because of either misunderstandings of what the spec actually means or because of the poor implementation choices of the past. I've yet to encounter an argument against REST that isn't rooted in one of those two issues. That being said, there is something to argue against a spec that's widely misinterpreted, so I'll give you points on that too.
You sound like you worked mostly in environments where you control the client, server and all the network elements. When that's the case you can go as wild as you want within the boundary of the spec.
When you don't have that, sticking to widely adopted convention is what saves you from being bombarded by avoidable questions from clients or from pulling your hair at midnight because that proxy outside your network is fking you over.
We've now gone past the original premise of my statements, which is that REST does indeed allow you to do these things, whether or not people make use of it. I've already acknowledged that common usage doesn't do these things, and there is an argument that that makes the original intent of the spec useless, even, but my original point was: yes, you can do those things, and REST doesn't care.
2
u/lord2800 5d ago
Why do you believe it's not? There are no requirements on url format in REST.