PUT It Away

06 Apr 2010

GET, PUT, DELETE and POST are four basic operations of HTTP. Many people think these are operations of REST, however Roy Fielding does not mentions them in his dissertation where REST architectural style is defined. The only constraint of REST regarding operations is the constraint of uniform interface (which by itself is problematic). However, these four operations are the de facto uniform interface of the Web. Having unsatisfactory definition this interface is frequently misused. And no wonder ...

Today I want to talk about PUT operation. Current definition of PUT makes it almost unusable. PUT is used for resource creation and modifications. Both use cases are problematic.

The problem with resource creation is that the client invoking PUT operation must specify resource URL. But how could client know the correct URL for a new resource? The server should maintain the URL namespace, not the client. The URLs should be cool, should not be reused and should follow application conventions. Believing that the client will maintain URL namespace consistent is like believing in any of The Eight Fallacies of Distributed Computing. The clients are out of control. They can be buggy, written by ignorant coders or just outright malicious. Server should maintain the order in URL space. But PUT operation does not allow that. It is placing the responsibility for URL creation to the client. Oh yes, the server can check client's request and enforce correct URL form. But such approach has many drawback. Firstly, it may be much more difficult to check URL than to assign it. Secondly, the URL assignment logic needs to be in many places (all the clients and the server). Thirdly, the client must be able to detect URL assignment problem and re-try which complicates the client. And it may not be able to succeed at all if client's and server's URL assignment policies are incompatible. And lastly, the URL assignment may take many round-trips. This makes PUT operation almost useless for resource creation. How much easier it would be to make server responsible for URL assignment?

If PUT is used to update a resource, it is assumed that the body of PUT request is new absolute state of the resource. There is no locking, neither optimistic nor pessimistic. There are no mechanisms that would enable consistency. Therefore you just cannot have consistency with PUT. Don't we need consistency in an open world-wide distributed information space? In fact we do need it, especially now as the Web becomes "writable". Yes, the server could still check the acceptability of new resource state, e.g. by making resource version part of resource state and checking it on each PUT (let's pretend for a while that mixing data and meta-data is a good idea). But if we accept such approach, what is the difference between PUT and POST? The interface is good if there is nothing to remove, if there is no redundancy. If PUT and POST are the same one of them should go.

PUT operation should either change or die. I strongly recommend not to use it in its present form.