# Are GET And POST Enough To Create RESTful Services?

| by Dilip Krishnan  Followers on Jun 23, 2010. Estimated reading time: 3 minutes |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

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 progress indicator, a target_uri for whatever’s being operated on, an op to identify the operation, and, when progress reaches 100, status and message fields 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.

Style

## Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

## Get the most out of the InfoQ experience.

### Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Because PUT and DELETE methods are idempotent

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

verbs in resource names

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?

Re: verbs in resource names

Pre HTML5 browsers' forms do not support PUT and DELETE. Some frameworks use hidden field to indicate PUT or DELETE.

Re: verbs in resource names

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.>

Re: verbs in resource names

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.

Re: verbs in resource names

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

Re: verbs in resource names

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.

Re: Because PUT and DELETE methods are idempotent

I agree with Mani.. it is useless to even have this discussion without the mention of idempotence..

Re: Because PUT and DELETE methods are idempotent

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.

Re: Because PUT and DELETE methods are idempotent

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.
Close

#### by

on

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

10 Discuss

Login to InfoQ to interact with what matters most to you.