Re: SOAP and the Web architecture

As pointed out, HTTP software that refuses long URIs isn't 'broken';
it's allowed by the spec.

More to the point, one of SOAP's requirements to be
transport-independent. As such, AFAIK the only approach to this
problem that preserves SOAP's architecture is to develop a means of
encoding the envelope into the request-URI.

I.e., it's not enough to say:
  http://www.example.com/service?arg1=foo&arg2=bar 
because one can't encode the entire range of SOAP envelopes possible;
while this encoding happens to be good enough for RPC, it isn't
possible to encode anything more complex. That's not to say that this
approach can't be done; it's just that the request isn't SOAP.

The way to do it would be to actually serialize the XML infoset as
URI parameters and/or query arguments. I.e.,
  http://www.example.com/service?*some XML Infoset serialisation*
In this manner, none of the expressiveness of SOAP is lost.

Unfortunately, doing so doesn't gain the benefits that are being
looked for; because there are a number equivalent ways to encode a
message infoset in section 5, I think we'll find that the same
service in fact would have a number of different URIs, based on how
client implementations encode the data.




On Mon, Aug 27, 2001 at 08:28:47PM -0700, Paul Prescod wrote:
> Hugo Haas wrote:
> > 
> >...
> > GET and POST, for HTML forms, address different problems.
> 
> Agreed.
> 
> >...
> > 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.
> 
> Agreed.
> 
> > 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.
> 
> Arguable. What spec. restricts the complexity of data sent through GET?
> I agree that there are various social expectations that URIs be simple
> and short and also that there may be some software that is poorly set up
> to handle long complex ones. But I'm not sure how much of this problem
> is really real and how much is merely expectation. Maybe if SOAP pushed
> the limits a little we could find out what HTTP software is really
> broken and fix it.
> 
> Anyhow, I would be satisfied if SOAP allows me to access simple web
> services with simple parameters in a simple way (i.e. through a URI) and
> if I need to deal with complex data I'll move on to more complex
> solutions. Most idempotent web services will have short, simple
> parameters just as most idempotent web sites do.
> -- 
> Take a recipe. Leave a recipe.  
> Python Cookbook!  http://www.ActiveState.com/pythoncookbook
> 

-- 
Mark Nottingham
http://www.mnot.net/