<<Tim Bray's article on RESTful Casuistry
<http://www.tbray.org/ongoing/When/200x/2009/03/20/Rest-Casuistry>
revisits an odd meme in the REST debates that I've been meaning to
discredit for a while.
Some people think that REST suggests not to use POST for updates.
Search my dissertation and you won't find any mention of CRUD or POST.
The only mention of PUT is in regard to HTTP's lack of write-back
caching. The main reason for my lack of specificity is because the
methods defined by HTTP are part of the Web's architecture definition,
not the REST architectural style. Specific method definitions (aside
from the retrieval:resource duality of GET) simply don't matter to the
REST architectural style, so it is difficult to have a style discussion
about them. The only thing REST requires of methods is that they be
uniformly defined for all resources (i.e., so that intermediaries don't
have to know the resource type in order to understand the meaning of the
request). As long as the method is being used according to its own
definition, REST doesn't have much to say about it.
For example, it isn't RESTful to use GET to perform unsafe operations
because that would violate the definition of the GET method in HTTP,
which would in turn mislead intermediaries and spiders. It isn't
RESTful to use POST for information retrieval when that information
corresponds to a potential resource, because that usage prevents safe
reusability and the network-effect of having a URI. But why shouldn't
you use POST to perform an update? Hypertext can tell the client which
method to use when the action being taken is unsafe. PUT is necessary
when there is no hypertext telling the client what to do, but lacking
hypertext isn't particularly RESTful.
POST only becomes an issue when it is used in a situation for which some
other method is ideally suited: e.g., retrieval of information that
should be a representation of some resource (GET), complete replacement
of a representation (PUT), or any of the other standardized methods that
tell intermediaries something more valuable than "this may change
something." The other methods are more valuable to intermediaries
because they say something about how failures can be automatically
handled and how intermediate caches can optimize their behavior. POST
does not have those characteristics, but that doesn't mean we can live
without it. POST serves many useful purposes in HTTP, including the
general purpose of "this action isn't worth standardizing."
I think the anti-POST meme got started because of all the arguments
against tunneling other protocols via HTTP's POST (e.g., SOAP, RSS, IPP,
etc.). Somewhere along the line people started equating the REST
arguments of "don't violate HTTP's method definitions" and "always use
GET for retrieval because that forces the resource to have a URI" with
the paper tiger of "POST is bad."
Please, let's move on. We don't need to use PUT for every state change
in HTTP. REST has never said that we should.
What matters is that every important resource have a URI, therein
allowing representations of that resource to be obtained using GET. If
the deployment state is an important resource, then I would expect it to
have states for /undeployed/, /deployment requested/, /deployed/, and
/undeployment requested/. The advantage of those states is that other
clients looking at the resource at the same time would be properly
informed, which is just good design for UI feedback. However, I doubt
that Tim's application would consider that an important resource on its
own, since the deployment state in isolation (separate from the thing
being deployed) is not a very interesting or reusable resource.
Personally, I would just use POST for that button. The API can
compensate for the use of POST by responding with the statement that the
client should refresh its representation of the larger resource state.
In other words, I would return a 303 response that redirected back to
the VM status, so that the client would know that the state has changed.>>
*You can read Roy Fielding's blog at: http://roy.gbiv.com/untangled/
*
*Gervas*
