POST supports three different method semantics:
- create a subordinate resource: this one is idempotent and should be the
primary way the POST method is used
- append a representation to the existing resource: this one is not
idempotent, so should be used with caution, but is still within the realm of
RESTfulness. It gives you the ability to add incremental information to a
resource (which might be returned via query strings). But if the information
is important enough to be referenced or retrieved, it's better to treat it
like a resource and create a subordinate URL.
- "process this": this one provides the means to tunnel RPCs through POST.
In some cases it's an appropriate use of POST (especially if the URL
represents a process rather than a resource), but if you find yourself using
POST this way, it's an indication that maybe you should go back and review
your resource design. Tunneling RPCs is not RESTful.

Optimally, if you want to update a resource, you should use PUT rather than
POST -- but that requires you to replace the entire resource. It doesn't
support incremental update. If you want to do something like "increment
value by 10", then you would need to use POST. But keep in mind that
"increment" is a verb. If you are being RESTful, you would not be trying to
push a custom verb through POST.

Anne

On 6/8/07, Todd Biske <[EMAIL PROTECTED]> wrote:


On Jun 8, 2007, at 11:30 AM, Anne Thomas Manes wrote:

>
> If you strictly follow the method semantics defined in the HTTP 1.1
> protocol, then it is RESTful. But HTTP 1.1 doesn't enforce those
> method semantics. That would be considered "abuse", though.
>

Is it true that a system that makes extensive use of the POST
loophole, but only does so where "the origin server is accepting the
entity enclosed in the request as a new subordinate of the resource
identified by the Request-URI" (from spec) would still be RESTful
then? Many WS-* implementations would certainly not qualify because
things that should be GETs are being tunneled as POST, correct?

The POST loophole concerns me. Clearly, you need POST because you
need the ability to make a relative change to a resource, but it
seems that as long as some form of update is happening, you can push
about anything you want through POST and still be considered
RESTful. It seems that this would be very tempting for someone to
take a very un-resourceful approach. Am I correct on this?

-tb

Reply via email to