|« 36 hours of fun and sun||People movers writ large »|
Once in a while, I'll run across posts like Benjamin Carlyle's on REST topics, where the author advocates minimal use of POST, instead preferring PUT for almost every request that has an enclosed entity.
Hogwash. That works fine for blogs and forums, but for real CRUD apps, POST is perfectly fine for updating a resource:
The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.
In other words, a URI handles a POSTed entity, but is or becomes a PUT entity. When I make a CRUD app, most of my URI's are "entities that accept annotations". It is a very rare operation for me to replace entire entities.
Or perhaps, I'm just thick. Maybe, Fielding is asking me to expose each attribute of, say, an Invoice resource as its own subordinate resource, with its own URI? But that way lies madness, IMO.
So, stealing the layout from Dave Megginson:
My piece was really about the intersection between REST and Object Orientation. REST essentially says "you should have few verbs and few content types, but many names". My view at present is that each verb should have understandable semantics from the client's perspective, particularly as they relate to the resource you're operating on. The wider semantic implications of the change are left to the server, and it is up to the client to be as aware as necessary of these extra semantics.
Outside of this REST perspective I don't have any comment on the use of POST. Within it, I see the need to for its semantics to be nailed down. The semantics I would currently apply to the traditional verbs are as follows:
GET: Get the state of an existing resource.
PUT: Make an existing resource assume state consistent with put content.
DELETE: Delete an existing resource.
POST: Create a new resource with state consistent with posted content.
I would rewrite your table as:
Create = POST
Retreive = GET
Update = PUT
Delete = DELETE
There are other ideas in play about how these verbs should be interpreted, but I think my rules are a consistent and complete set. I don't think the semantics of your table are well-defined for POST. I think that "handle" is too vague a term.
You say in your article, "When I make a CRUD app, most of my URI's are "entities that accept annotations"". I would be more specific, and say "most of your URIs are resources that create other (annotation) resources". In this sense, you are using POST in the same way as I proscribe. I would generally see the kind of URI you POST to as being different to the kind of URI you PUT to. One is like a factory, and the other a regular object.
Thanks for your feedback :)
Keep it coming.
Thanks for the comments, Benjamin!
One is like a factory, and the other a regular object.
Mark Baker has used the terms "container" and "resource" to mean the same thing, I think. http://www.markbaker.ca/2002/08/HowContainersWork/
However, I diverge from his model, wherein he says, "...most resources are also containers. That is, for every resource, you can conceptualize a reason for it to also be a container for something." You said essentially the same thing above ("most of your URIs are resources that create other (annotation) resources"). That isn't true for my apps--most of my domains have very flat objects (Directory, Invoice, Inventory, ...) that are related to each other, rather than being contained by each other.
That doesn't bear on the choice of PUT vs. POST, however. ;) But I think I understand your point-of-view better. In particular, I can see how PUT applies more often to an existing resource, whereas POST applies more often to a container. The fact that containers are resources doesn't help much. :/
I hope that since the date this article has been published you got a deeper knowledge of PUT and POST.
Anyway, you should read this:
|<< <||> >>|