Re: SOAP and the Web architecture

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

If an arbitrary limitation of the software gets in the way of meaningful
useful real-world uses then it is lacking a feature whether we call it
broken or not.

> 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 agree this far.

> 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;

It isn't necessarily the case that we have to support EVERY SOAP
envelope. From a purist point of view I would advocate that. But from a
practical standpoint, I would be happy with much less. I would like to
not have to choose between SOAP and URIs for the sorts of things URIs
are already good at (e.g. get me a stock quote, what's the temperature,
please convert this currency value).

> 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.

It isn't SOAP as defined today. It can easily imagine a parallel
universe where  method=mymeth&arg1=foo&arg2=bar maps into:

<SOAP:Envelope
  xmlns:SOAP='urn:schemas-xmlsoap-org:soap.v1'>
 <SOAP:Body>
  <mymeth>
   <arg1>foo</arg1>
   <arg2>bar</arg2>
  </mymeth>
 </SOAP:Body>
</SOAP:Envelope>


> 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.

That's another way but now you are trading off human-readability which
is a major advantage of both URI's and XML (that's why we don't use
UUIDs and ASN.1!). I think a=b&c=d would be a minimized format. The
serialization would be an expanded one.

> 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.

Just as there is a canonical XML, canonical Unicode, etc. there should
be a canonical section 5.

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook

Received on Tuesday, 28 August 2001 16:12:25 UTC