Mike Amundsen asks, in an post that examines alternatives to how one might develop RESTful services in environments constrained to a choice of using just GET and POST.
Every once in a while i get into a discussion about the REST arch style w/ a person who is under the impression that, unless you use the HTTP methods PUT and DELETE, your app is not RESTful. this is not correct.
In an attempt to answer this questions he proceeds to answer a few questions that verify that as long the right HTTP methods are used for the appropriate operations, a service can be considered RESTFul.
Is it safe?
He reiterates in order that intermediaries determine safety of an operation by examining the HTTP methods. As long as the intent of the operation, expressed via the HTTP methods, and the implementation of that request match, the operation is considered safe.
it's important that implementations do not use safe methods (e.g. GET and HEAD) to perform unsafe operations (e.g. writing data). […] since HTTP defines GET as "safe", caches and other proxies will assume (based on the spec) that it's fine to perform "pre-fetch" on these URIs and/or cache and replay the responses as needed.
Is POST is not enough? [Do we need PUT and DELETE as well for unsafe operations?]
Though much of the examples and literature available on the subject suggests it, he emphasizes that RESTful service interfaces are not always just CRUD interfaces.
[…] another common notion is that using only POST for all write operations is not RESTful. IOW, you can't claim your implementation supports REST unless it utilizes PUT and/or DELETE. this incorrect assumption is often a side-effect of viewing REST only through the lens of CRUD operations; that REST == CRUD over HTTP. again. while it is possible to do CRUD over HTTP, that's not REST; that's CRUD over HTTP.
He goes on to quote Roy Fielding; who asserts that “It is okay to use POST”
We don’t need to use PUT for every state change in HTTP. REST has never said that we should.
But can i really do it all w/ just GET and POST?
“sure you can;” He say’s “it's been done that way for many years. nothing magical is needed. no special headers; no action arguments in the URI; no method parameter in the body of the message.”. He goes on to give an example of queued operations on a server.
for example, expose public resources where writing to the server is handled via requests that are added to a list for processing:
POST /users/pending-updates/ OR POST /users/pending-deletes/
This model is very similar to the ideas expressed by Tim Bray in the design of Sun’s VM API, which he refers to as Slow REST. The idea is based on Craig McLanahan’s proposal for Handling Asynchronous Operation Requests.
For any and all PUT/POST/DELETE operations, we return “202 In progress” and a new “Status” resource, which contains a 0-to-100
progressindicator, atarget_urifor whatever’s being operated on, anopto identify the operation, and, whenprogressreaches 100,statusandmessagefields to tell how the operation came out. The idea is that this is designed to give a hook that implementors can make cheap to poll.
Mike concludes his post saying, for situations where the use of HTTP methods is either constrained by network or by limitations in the clients' useragent's ability to handle verbs other than the standard GET and POST, the service needs to make adjustments that “guide” the client towards the right representations, HTTP methods and uri’s
since HTTP abstracts interactions into resources w/ representations addressed via URIs, making runtime adjustments is not only possible, it's designed into the protocol. by combining these levels of abstraction w/ the hypermedia constraint described in Fielding's dissertation you can achieve a very flexible implementation that is not only HTTP-compliant, but also supports key principles of the REST architectural style across multiple environments; even ones restricted to using only GET and POST.
Be sure to weigh in your opinions here as well the original post.