CRUD not only good for, but is the only consistent way to build REST over HTTP(blog.dhananjaynene.com) |
CRUD not only good for, but is the only consistent way to build REST over HTTP(blog.dhananjaynene.com) |
A design that uses only opaque UUIDs as names for resources and reveals them to the client via links in the responses is perfect REST. Clean-looking URIs are a distraction, except that they tend to be easier to preserve across software rewrites.
HTTP method + a Unique URI are the essence of the Uniform interface constraint of REST. They are very much a part of REST. How the real world uses them has no bearing on their validity. This has to be managed by better informing the real world not by questioning the very notion itself. Linking via hypermedia is an essence of the HATEOAS constraint of REST. Both are orthogonal yet complementary aspects of REST. A discussion can be had about one without necessarily talking about the other as this blog post does.
On the other hand transparency vs. opaqueness has nothing to do with REST API design per se. All REST recommends is that clients shouldn't design themselves to assume specific semantics into the URI substructure nor should the services guarantee them. However structured design URIs do not at all fall foul of REST from an API design perspective, and help both development and debugging substantially.
I suspect you've introduced both issues related to Client API usage and used them to question serverside API design. The issues are not incorrect but the level of abstraction at which you choose to address them is something I would differ with.