01/26/10 :: [REST] PUT vs POST [permalink]
My post on REST, Processes and Resources is the most read on ebpml, month after month (I am not sure who linked to it). I stand by every word in this post, but I would like to reiterate a truism that apparently even some of the most senior architects and developers seem to ignore.
Lots of people who have read about REST would tell you that the "resource representation" pattern is a great progress in information system construction, in particular because you can "PUT" the representation back. That's in line with the DTO pattern that CORBA or JEE aficionados are/were so accustomed to. Of course, they often pass on the fact that having a standard "Change Summary" definition as the resource representation would be a terrific feature to have, one day the RESTafarians will look around and discover (Stefan?) that the industry had already solved all these problems well before they even started to understand them: Microsoft came out with the DataSet concept around 2003 and later, in 2005, SDO generalized that concept in both Java and .Net world. But it is so easy to ignore all the work that has been done and start over. Right.
So here the argument goes, REST is great because I can PUT stuff back. Complete Freedom, they argue. This is what Bill DeHora stated a while back:
So, in a business process where GET and PUT (and friends) apply to *all* business entities and are not just per process defined methods, why can't I GET the state and have a well-understood formal document returned citing the state of that entity? Or for that matter PUT the updated state to that entity? What's the actual limitation induced by applying REST?
For those of you who still believe that PUT is all you'll ever need, let's look at the physical world: everything is in a "given" state. From the smallest particle to the heaviest piece of equipment. Each state has well defined transitions to other states. I can't "PUT" a particle in any state I want, I can't PUT an elevator or a can of soda in any state I want. I express an intent and the system reacts to that intent. Actually, state is such a profound foundation in our universe that it defines "time". Time only exist because the universe can never return arbitrarily to a given state. If that were possible (who would decide which state to go to?), time would simply not exist.
Before you get too bored with metaphysical considerations, let's go back to information system construction. Information entities are like physical objects. First, they often represent physical objects and model their primary "States", if they are a more abstract concept, say like a contract, they nearly always have distinct states which control their lifecycles.
The question becomes how do you express the intent of transitioning from one state to another. I say intent, because, just like in the physical world THY SHALL NOT PUT STATE directly into the information entity. Yes there are attributes, say like the color of a soda can that can change idempotently (I am extending the definition of idempotent here) and then there are attributes which represent the states of the information entity which can only be changed by the entity itself. The business logic that transitions from one state to another must be owned by the entity. If not? if not, terrible things happen when you have more than one consumer of that entity, you start duplicating the state/transition logic in the consumer of that entity. You get the picture. In the days we built monolithic systems, there was little value in correctly factoring that kind of business logic. In the SOA days - and I would argue the principal reason people fail at SOA - THY SHALL LET THE ENTITY DECIDE FOR ITSELF whether it can transition from one state to another. Most people do SOA by exposing a Data Access Layer as a bunch of Services. They encourage people CRUDing. Worse, people like Dave (Microsoft) Chappell would tell you that the only thing that works is a "data service", otherwise SOA is a failure. CRUD rules at Microsoft... I can safely say that he doesn't understand a thing about SOA or SCA for that matter. Now, when the RESTafarian like Stefan, Bill DeHora, Bill Burke, Jim Webber, ... come to you and encourage you to PUT up with CRUD as a key success factor for your "SOA", I smile loudly. WOA is the "WOrst Atrocity" ever pushed down the IT throat.
Now, people might tell you that PUT can express an intent, why not (Roy would disagree), they can tell you, but we use POST to encode all intents. I say, why not? as long as the logic to transition from one state to another resides on the resource side, but have we gained? Nothing, we have just found another encoding (actually 2, PUT or POST) and we have lost so much (bi-directional interfaces, events, orchestration, versioning, we have coupled access and identity ...). So what is the point? What is the point of yet a new encoding? Browser access, ok, so what, do you need to displace entire technologies for that? Is that a game? I am amazed, in awe actually, at how such bogus arguments took hold in our industry, how little, nice to hear, stories ended up where they are today. Yet, REST is nowhere, no proof of any massive and successful use outside the browser.
So if you want to use PUT the attributes that can change idempotently, great, if you want to use POST for invoking actions on a resource (encoded as a noun), even better, but don't tell me you invented anything. Information systems have been working on these principles for 8000 years, i.e. as long as man created information. They didn't need computers, the Web, Stefan, Steve or Bill to figure that out.
The (other) REST is a fraud, and there is nothing clearer today.
