RE: SOAP and the Web architecture

--- "Jones, Matthew" <> 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."

> Many search requests and other requests (ie stock price) use post.  I
> always
> inferred that post was supposed to be more general than get.

That's certainly how it's *now* used (i.e. for both update and
retrieval purposes), largely because, as you quite rightly point out,
there's no commonly imposed limit on the payload of a POST request. 
But I think that the RFC shows that that's not what it was intended for
(although it certainly seems to serve that purpose quite well). 
Whether SOAP decides to follow HTTP's existing practices or its
intended design is probably not that big an issue, but it should
probably do one or the other knowing what it's *not* doing.  :-)



Good, cheap, fast: pick two.

Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger

Received on Monday, 27 August 2001 15:37:06 UTC