Re: SOAP and the Web architecture

* Paul Prescod <> [2001-08-27 12:11-0700]
> > Modulo Larry's note about "don't rehash; send links", I really do not
> > understand the objection:
> > 
> > > The gist of the problem is that the current HTTP binding uses HTTP POST
> > > requests.
> > 
> > IS there a fundamental difference between sending a soap message and
> > sending form data?  If so, what is it?
> One difference is that when I build an HTML form I have a choice of GET
> or POST. Google uses GET. Babelfish uses POST. In fact I believe that
> GET is the default.

GET and POST, for HTML forms, address different problems.

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.

Hugo Haas - W3C - - tel:+1-617-452-2092

Received on Monday, 27 August 2001 16:29:24 UTC