Re: Issue 133, and permitting no body

At 05:12 PM 2/5/2002 -0500, wrote:
>... I particularly understand
>it's applicability to the many situations in which there are stateful
>resources, and a desire to create/update/access them in a consistent

Resources are things you GET representations from.  This barrier --
you don't get resources but only representations -- has to work in
the opposite direction.  So you can't create/update resources.  You
can only send in representations.

That's why the Web didn't buy PUT.  By that I mean we did a big experiment
and the results are in: POST wins by a landslide.  Yes there are some
confusing factors, but POST has exactly the property of sending in a
representation (ok, just some funny data) with an impact on later GETs
That impact is determined by the server in some encapsulated way, to
preserve its barrier between representations and resources.  That barrier
is key to web server sanity.

The other magic of POST has not (yet?) been realized in web services.
Critical to the progress of web technology has been the
ability of web site developers to instantly upgrade their system by
changing the content of forms downloaded by GET then POSTed.
Legendary are the annals of distributed systems developed, hyped,
deployed, and then frozen in time.  Any system that does not
incorporate an upgrade solution as effective as web apps will join
them.  Web services included.

Returning to Stuart's thread, this line of reasoning says: "don't worry
about the POST response, worry about how the client formed the message".
Semantic ignorance is bliss on the client side: the less it knows the
more we can accomplish.  If web service requires simultaneous upgrade
(homogeneity and central admin), we have created a lot of angle brackets
for nothing.

John J. Barton          email:
MS 1U-17  Hewlett-Packard Labs
1501 Page Mill Road              phone: (650)-236-2888
Palo Alto CA  94304-1126         FAX:   (650)-857-5100

Received on Tuesday, 5 February 2002 20:09:30 UTC