RESTful web services and HTTP verbs

Question

What is the minimum set of HTTP verbs that a server should allow for a web service to be classed as RESTful?

What if my hoster doesn't permit PUT and DELETE?

Is this actually important, can I live happily ever after with just GET and POST ?

---

Update: Thanks for the answers folks, Roger's answer was probably best because of the link to the Bill Venners and Elliotte Rusty Harold interview. I now get it.

---

Answer 1

If you just use GET and POST, it's still RESTful. Your web service may only do things which only required GET or POST, so that's fine.

Answer 2

Yes, you can live without PUT and DELETE.

This article tells you why: http://www.artima.com/lejava/articles/why_put_and_delete.html

While to true RESTafrians this may be heresy, in the real world you do what you can, with what you have. Be as rational as you can and as consistent with your own convention as you can, but you can definitely build a good RESTful system without P and D.

rp

Answer 3

Today's web browsers only handle GETS + POSTS. In Rails, for example, PUTS + DELETES are "faked" through hidden form fields.

Unless your framework has some workaround to "support" PUTS + DELETES, don't worry about them for now.

Answer 4

You can also use X-Http-Verb-Override:DELETE inst. of HTTP DELETE. This is also usefull for Silverlight clients who cant change the HTTP verbs and only support GET and POST...

Answer 5

REST allows for breaking protocol convention if the implementations of the protocol are broken (so that the only non-standard things you do are to get around the broken parts of the implementation). So it is allowable within REST to use some other method to represent generally unsupported verbs like DELETE or PUT.

edit: Here is a quote from Fielding, who is the one that created and defined REST:

A REST API should not contain any changes to the communication protocols aside from filling-out or fixing the details of underspecified bits of standard protocols, such as HTTP’s PATCH method or Link header field. Workarounds for broken implementations (such as those browsers stupid enough to believe that HTML defines HTTP’s method set) should be defined separately, or at least in appendices, with an expectation that the workaround will eventually be obsolete. [Failure here implies that the resource interfaces are object-specific, not generic.]