Re: PUT

Hi,

Section 9.6 of RFC 2616 explains the difference between PUT and POST. The former
affects the state of the specified resource. The operation is not supposed to be
delegated to another resource. The latter provides no such guarantee.

There is, in my opinion, no guarantee the representation of the entity will be preserved
by the handler of the PUT operation. This is of course its most common use, but the
guarantee is not stated in that section of the RFC. So PUT is simply more restrictive
by being explicit about the affected resource.

The section also doesn't describe any relationship with the GET operation. As a consequence
it is not guaranteed that the change of state caused by a PUT will be visible through a
subsequent GET.

I think all this is very normal because the specification doesn't impose any semantics. The
semantics depend on what the resource is, which is something that must be expressed
through other means.

I believe it is not necessary to preclude the PUT operation in the XForms specification. First,
the XForms specification is not the place to decide on the value of PUT. If some day PUT is
no longer considered a good thing, the HTTP specification will have to be updated to
reflect this. All specifications leaning in some way on HTTP will have to be adapted at the
moment it is decided to upgrade them to the new HTTP specification.

Second, in the current situation it makes sense to have PUT. A use case could be for example
an asynchronous message delivery resource which is addressed with a URI. Basically, a
message queue would be behind the URI. This usage complies to the decribed meaning of
PUT. It is explicit about the affected resource and it modifies its state because a message
is committed to it. The GET operation would in this case not even be implemented for the
resource.

Because of the richness of XForms it is not unlikely people would want to use an
application of it to put messages on a queue. Note that asynchronous data entry systems
like that are quite common in the mainframe world for example. Such applications are
both more productive for the end-user and more resource effective, because resource
usage is under control, something which is not the case for synchronous interactions.
We are talking about another culture then of course.

Regards,

Werner.
-- 
Werner Donné  --  Re BVBA
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be

Received on Friday, 18 January 2002 09:20:25 UTC