Just because your application handles PUT and DELETE doesn't mean your application is even remotely restful. Even allowing for OPTIONS doesn't necessarily mean that your application is RESTful. Being a RESTafarian doesn't mean that you know how to make server-side-software-x handle a PUT request.

In fact, there seems to be some rather big confusion about what REST is. This isn't too surprising, as the barrier to entry as a RESTafarian guru is pretty high. You have to be able to read and understand Roy Fieldings essay.

The RESTful waters are muddying, two new terms are being created: Hi-Rest and Lo-Rest.

...REST is a fairly subjective (and sometimes divisive) term. To get a more accurate picture of what we've done so far, I'll break this category in two: Lo-Rest, which is the use of HTTP GET (or equiv) for information retrieval/query, and Hi-Rest, which is characterized by the use of HTTP PUT and DELETE (or equiv) for doing update.

--Don Box

This is all very confusing and wrong. Thankfully Dimitri Glazkov has started coming out to say so, and I'll add my voice to his choir. Lo-Rest is just barely good HTTP, and is no where close to being RESTful. REST in fact is not a subjective term, it is very much an objective term. REST is a set of architectural constraints to a system. It should contain a specific set of features as laid out by Chapter 5 of Fieldings dissertation.

In Short, REST, whether, high, low, medium, or super-powered should contain the following features:

• Statelessness - communication should be stateless, so that each request from the client must contain all the information necessary for the server to understand the request. Note that the server still may make use of state information to (for instance) validate a request, etc. The important thing is that the client does not have to depend on the server for context of the request.
• Cacheability - Each resource transfered to and from the client and server should be marked as cacheable, or non-cacheable (at the very least).
• Uniform interface - A RESTful system will provide a Uniform interface with the following features:
  • Identification of resources A RESTful system will contain one or more Resources, being a conceptual identifier of the target of the service. (The weather at Calgary International Airport; the price, description and other features of the book "American Gods" by Neil Gaimen, etc.) an URIs for the resources, Universal Resource Indicators, being the location of each resource.
  • Manipulation of resources through representations A representation consisting of a series of bytes (a plain text number of the degrees in centigrade, a JPEG image of the book cover, an XML document containing all the weather information, or even an XHTML fragment containing an XOXO list of book attributes). Note that there does not have to be a 1 to 1 relationship between the representation of the resource, and the resource itself. The resource is decoupled from its representation.
  • Self-Descriptive Messages Meta-data, pure and simple. A representation of a resource will have meta-data like its content-type. A resource will also have meta-data that may be independent from its representation, such as alternate representations. There may also be meta-data about the connection, (cache control information and authentication come to mind.)
  • Hypermedia as the engine of application state If applicable, there should be some kind of link to the next state of the application within the current representation sent to the client. The most obvious example might be that a POST request that creates or modifies a resource should return a pointer to a representation of that resource, either in the form of an HTML page containing a link, or even just a HTTP 302 Found, or more semantically, a HTTP 303 (see also).
• Layered - Each layer inside of a REST system cannot see beyond the layer it is connecting to. For example, the "client" that our RESTful service is talking to, might not be a client at all, but might be another server, such as a proxy, instead. As architect of the RESTful service, we don't care, we just treat it as a client and act on the request.
• There is an optional constraint to the REST style, and that is that a REST system may also be constrained by code-on-demand. Which is to say, you can make it a feature of your system that code is to be downloaded and executed by the client (Java, Flash, Javascript, etc.) as part of the representation of the resource.

Thats it.

That is what it means to be restful. All this jazz about HTTP error messages, methods beyond GET and POST, its all just good HTTP baby. It has very little to do with actual restfulness or not. All the HTTP conformance in the world wont mean a thing if your application stores client state on the server. You still won't be RESTful.

Hopefully this helps.