Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Are GET And POST Enough To Create RESTful Services?
Posted by Dilip Krishnan on Jun 23, 2010
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.
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
Because PUT and DELETE methods are idempotent
by
mani doraisamy
Posted
Re: Because PUT and DELETE methods are idempotent
by
David Tkaczyk
Posted
Re: Because PUT and DELETE methods are idempotent
by
Dilip Krishnan
Posted
Re: Because PUT and DELETE methods are idempotent
by
Mike Amundsen
Posted
verbs in resource names
by
James Watson
Posted
Re: verbs in resource names
by
Umesh Rajbhandari
Posted
Re: verbs in resource names
by
Aslak Hellesøy
Posted
Re: verbs in resource names
by
mani doraisamy
Posted
Re: verbs in resource names
by
Aslak Hellesøy
Posted
Re: verbs in resource names
by
Dilip Krishnan
Posted
-
While POST is not. You should try and map update & delete of your resource to PUT and DELETE methods of REST. If it fails, you can retry it. It is a good practice for all distributed systems, especially for REST which doesnt support transactions.
thanks,
mani
manidoraisamy.blogspot.com -
POST /users/pending-updates/ and POST /users/pending-deletes/ are clearly attempts to avoid putting verbs in resource names but fail the smell test. I'm not saying that one should never use this technique but it does appear to violate basic REST principles.
Out of curiosity, in what kind of environment are the HTTP operations restricted to GET and POST? -
Pre HTML5 browsers' forms do not support PUT and DELETE. Some frameworks use hidden field to indicate PUT or DELETE.
-
POST /users/pending-updates/ and POST /users/pending-deletes/ are clearly attempts to avoid putting verbs in resource names but fail the smell test.
Isn't restful services all about modeling scenarios as resources so that it feels natural to use them while leveraging the characteristics of the web as a platform? To me it seems natural to model such a "container" resource that one can put resources into and and manage.
Out of curiosity, in what kind of environment are the HTTP operations restricted to GET and POST?In addition to browsers, certain server stacks do not support all the http verbs. Not to mention firewall/network restrictions.> -
It's the HTML 4 spec that doesn't support other verbs than POST/GET in forms. Even new browser won't be able to use other verbs if a HTML document uses a HTML 4 doctype.
-
Umesh/Aslak,
Even though form method does not support PUT & DELETE, browsers have always supported them. You can use javascript libraries like jQuery and build full REST complaint applications even in pre HTML5 browsers. homework.nwsnet.de/news/9132_put-and-delete-wit...
thanks,
mani -
Sure, XMLHttpRequest doesn't have this limitation (and never had AFAIK). Still, a plain HTML4 FORM with method="PUT" or method="DELETE" (and no javascript) will issue a HTTP GET request.
-
I agree with Mani.. it is useless to even have this discussion without the mention of idempotence..
-
Speaking for the author, the point however wasn't to dismiss PUT and DELETE as inessential for REST.
The purpose was to look at strategies for doing idempotent operations using just GET and POST as primitives. -
Speaking for the author, the point however wasn't to dismiss PUT and DELETE as inessential for REST.
The purpose was to look at strategies for doing idempotent operations using just GET and POST as primitives.
DK:
thanks for including my recent blog post here. yes, the point of the article was how one _can_ do RESTful work with only two of the HTTP methods (one read, one write), not how one _must_ do it w/ only two HTTP methods (e.g. don't use PUT/DELETE). for example, i work in some very high-security cases where web browser scripting is not allowed.
i see James Watson doesn't like my URI naming, he can use /q1w2e3r45/ and /y6u7i8o9/ instead; the implementation is the same.
finally, i possibly did not make it clear that the implementation i illustrate achieves idempotency via a message body design (the media type transfered in each POST) that can be repeated (ala PUT and DELETE) without other side effects.
again, thanks for referencing my post.
10 comments
Watch Thread Reply