On May 6, 2008, at 1:06 AM, dev wrote:
> >want to know how to do everything in a PUT or DELETE instead of
> >any of the other HTTP methods. That is wrong. That is thinking
> >HTTP is just a "Save as..." dialog.
>
> At first I thought that using non-standard methods like PATCH would be
> wrong as it wouldn't allow for serendipitous reuse.
>

Serendipitous reuse comes from providing a URI for everything that is
of value as a resource (even when that value is not used by your own
application). As long as you are using GET for retrieval, then reuse
will be there. POST can be used in serendipitous ways as well, but
there are no special tricks in HTTP that make POST actions any more or
less reusable than any form of RPC/RMI -- we simply rely on the
media type telling us where to POST to describe the service on the fly
(late-binding is always better than compiled contracts because any
late binding can self-identify its own expected "contract").
More importantly, it is very hard to see that it is safe to reuse
a POST in unforeseen ways, whereas that is required of GET.

Even when POST is used to perform the equivalent of GET, for whatever
crazy reason, it can be compensated somewhat by responding to the POST
with 303 or 201 + Location, or simply by limiting the 200 response
content to a list of references to reusable resources.

PUT, DELETE, and PATCH are essentially editing operations on the
mapping from URI to representation. In many cases, those will translate
down to what is essentially file-like CRUD operations, but only for
a very small subset of resources. If you think of it in MVC terms,
then those operations should only be active when M=V. It is the
application's job to determine when M=V; i.e., which models are
capable of being edited by representation exchange, which models can
be edited by indirect action on some other resource(s) (e.g., edit
links in Atom or wiki post forms on pages), and which models can't
be edited at all via HTTP.

In any case, there are plenty of RESTful services that do nothing
but GET and POST. The key is how those methods are used, not what
methods are used. To give a specific example, what makes a wiki
more or less RESTful is almost always determined by how it (ab)uses
GET and sessions -- whether it uses PUT or POST for editing pages
is sugar topping in comparison.

> But what you are
> saying is using non-standard methods is fine as long as there is an
> engine which can tell the client what to do next. That engine should
> support introspection via GET. Is this correct ?
>

I wouldn't go as far as saying all "non-standard methods" are fine.
The methods still need to be standardized in order for intermediaries
to take part in the conversation and for generic clients to know how
to follow the instructions. The methods still need to be resource-
neutral
in terms of semantics. However, for actions that do not benefit
from intermediaries (non-retrieval actions), the focus of REST is to
make the results visible as reusable resources after the action is
complete rather than worry too much about the standard-ness of any
non-GET method name.

....Roy