I am now wavering in my support for the HTTP verb PUT. I used to think that it had wide applicability but now I am beginning to question that. Clemens Vasters talks a little about the applicability of using PUT to create a new resource. From the experimenting with RESTLog I know that creating a resource is better done by a POST and then returning the URL of the created resource in the Location: header. You avoid, or can more easily control concurrency problems when the URL creation is specified by the server. ( Now that I think of it, what's wrong with a belt and suspenders strategy and also delivering that new URL in a SOAP envelope...)
Any way, Clemens goes on to point out problems with updating a resource with PUT. Now Sam Ruby thinks this is just a SMOP. It actually may be, if you use ETags to guard against concurrent updates. Even if this were a solvable problem, there is a deeper problem from the semantics of PUT. You see, PUT is supposed to be an exact copy of what you get if you do a GET, modulo someone else updating things between your calls. Now I originally thought this was a good way to do updates to stories in RESTLog, but as my work progresses I realize it may not be the best way to go. For example, what if I want to add a field to the 'item' to track the last time it was updated? The best place to track and update that information would be on the server. So now I end up taking in an updated 'item' via PUT but now RESTLog would have to modify it to update the 'lastUpdated' element. I won't be returning the same exact XML as was just PUT to the server. This kind of updating of the content is exactly the difference between PUT and POST. After my run-in with XForms and DELETE I am beginning to think the only two verbs I can count on are GET and POST. Just two verbs. Hopefully I won't lose any more. You can't go to zero verbs, can you?