With all this talk about High and Low REST, I noticed something in a post by Mark Nottingham:
Don has effectively made the observation that a lot of other
people (especially of the Web services sort) have made; while the
benefits of GET’s transparency are obvious, they’re less
apparent for PUT and DELETE, so why not just take the easy (lo)
road and use POST?
I think there are two answers; 1) hopefully, we’ll have some
concrete benefits for that transparency some day (think offline),
and 2) thinking in terms of GET/PUT/DELETE first — using POST
only as an escape hatch — leads you down a path where your
application will be using transparent methods a lot more than
I’ll use my first post here to repeat the ideas from Bill’s post…
I think a cargo cult of REST has indeed emerged, and I’m seeing evidence of it on the ground, far from SOA discussions. I’m seeing REST evoked as something that is inherently good. I’m seeing people ask for REST support in their frameworks. I usually know what they mean, but their requests seem to be driven by the truthiness of REST, not the utility.
For instance, I often get annoyed with URI design discussions, where people put great importance into abstract design issues that no one else will notice or care about. In HTTP (and REST) URIs are supposed to be opaque strings, so why the obsession? I call bike shed. People are tackling the pointless decisions first, because they are low-stake and easy to think about. It also comes from an inversion of logic: good things are generally aesthetically pleasing; but many things that are aesthetically pleasing are superfluous and distracting.
What’s useful is that REST design doesn’t promise anything more
than it can deliver. It doesn’t promise anything general about the
body of the response (except I suppose that
Content-type and other metadata will be accurate). It doesn’t promise anything about the URI. The use of verbs is in part to make the URI more opaque, so instead of rewriting the URI to express new actions, you use different verbs on the same URI. GET actually means something to intermediaries. POST, PUT, and DELETE only really mean something to humans. Which is okay, but it’s not interesting architecture.
It’s not bad to use these verbs, it’s just not particularly useful. I think High REST may be the result of people who just can’t help but make architecture. Low REST is people who are recognizing emergent architecture. REST isn’t a new idea, it is the recognition of the good ideas that are already around us. And like design patterns, the description is turning into prescription, and as with patterns we are seeing people use REST to justify premature architecture — probably a much worse sin than permature optimization.
I look at a protocol like OpenID which is
wedded to HTTP and HTML — and even intimately connected to
those poorly-specified browsers that we all can’t help but hate — and
I think that’s great architecture. It’s not great because it is
pretty underneath (it isn’t), it is great because it solves a hard
problem inside fixed constraints without exceeding scope. It’s RESTful at heart, but not RESTful in form.
If there aren’t concrete benefits to using PUT or DELETE over POST,
then why should we care? What hard problem is made easy? High REST seems to be uncovering non-problems.