RE: SOAP and the Web architecture

Laird wrote:
>--- "Jones, Matthew" <MJones@NetSilicon.com> wrote:
>> It never seemed to me that post was particularly for updating an
>> object.
>> Perhaps that is implied by a content type of multipart file upload,
>> but for
>> url form encoded I wouldn't infer
>> update-this-resource-please-oriented.
>
>Why not?  Thus speaketh the RFC:
>
>"The POST method is used to request that the destination server accept
>the entity enclosed in the request as a new subordinate of the resource
>identified by the Request-URI in the Request-Line. POST is designed to
>allow a uniform method to cover the following functions: 
>
>* Annotation of existing resources; 
>* Posting a message to a bulletin board, newsgroup, mailing list, or
>similar group of articles;
>* Providing a block of data, such as the result of submitting a form
>[3], to a data-handling process;
>* Extending a database through an append operation."

I should have said ...I wouldn't infer update-this-resource-please-oriented,
only.

When I wrote this I was responding to the origional statement:
>I think that the original objection stemmed from the fact that POST was
>conceived to augment or update the object at the URI that's being
>posted to (e.g. add to a bulletin board, put new stuff into a database,
>cause a process to start, etc.).  Form data, submitted via POST, was
>thought to be the usual way in which you'd update an object, i.e. it
>was entirely in keeping with the intended POST semantics.
>
>(For completeness: GET was to be for retrieving things, static or
>dynamic; PUT was to be for adding a new object.)

Perhaps I misunderstood the statement but I took it to mean that
update-this-resource-please-oriented was the (only) purpose of a post and
not one purpose of a post.  The last statement commenting on the difference
between each was what was troubling to me, probably because I misread PUT to
be POST, sorry.  

Matthew Jones
mjones@netsilicon.com

Received on Monday, 27 August 2001 16:04:42 UTC