RE: SOAP and the Web architecture

-----Original Message-----
From: Hugo Haas []
Sent: Monday, August 27, 2001 1:29 PM
Subject: Re: SOAP and the Web architecture
Hugo writes:
>A GET request asks for the representation of a resource. For example,
>you can ask some information about a movie using a particular URI
>(e.g. <>).
>With POST, you submit some information and your request is going to
>have some side-effects (e.g. you submit your name and credit card
>number at <>).
>The default is GET because (I guess), in most cases, the form
>submission will have no side-effect.
>> Will SOAP allow me to choose? Also, I'd really appreciate it if SOAP
>> would allow me to choose how much or how little to put in the URL-line
>> instead of in the message body. But that implies a tighter binding
>> between SOAP and HTTP than just using HTTP as a more or less invisible
>> transport.
>The same way it makes sense to use POST sometimes instead of GET (and
>vice versa) for HTML forms, I think that the use of SOAP over HTTP
>POST sometimes makes sense, and sometimes does not.
>I will note that, depending on the kind of request which is done, it
>might not be achievable with GET even though it's idempotent, e.g. if
>the data structures are very complex.
>The idempotency of Web services should be advertized in order to
>achieve that.

POST does not have side effects anymore than GET does.  You can send exactly
the same form via POST or GET and it will do exactly the same thing.  The
fact that POST has more general capability might make it more likely that
POST requests have side effects but there is nothing inherent in the POST
that makes this so.  Furthermore GET is not necessarily idempotent, you can
certainly write a service so it will be idempotent or not but GET does not
guarantee idempotency.  

Matthew Jones

Received on Monday, 27 August 2001 16:45:25 UTC