Re: whenToUseGet-7 Making SOAP Restful

I am working through your suggestion. 

My problem with SOAP today is that the specification strongly
disincentives a REST-ful approach. (this is why I am not at all happy
with Mark Baker's prose-only solution)

I think that an ideal solution will combine the virtues of SOAP and
HTTP. As you say:

> * One of SOAP's great strengths in comparison to HTTP is the richness of
> its header and extensibility architecture.  In addition to use of XML
> syntax, it provides mechanisms (mustUnderstand) to facilitate the safe use
> of extensions in combination.  Capabilities such as digital signatures,
> authentication, transaction control, etc. can be encoded using these
> facilities, and MAY be implemented end-to-end when going multiple hops
> (e.g. MQSeries + HTTP).

I think that a true solution to this problem would allow digital
signatures, authentication, transaction control, etc. to be encoded in
an HTTP message, no matter WHAT the method. 

*If users must choose between HTTP's features and SOAP's, then we have
failed (at least in part).*

So I do not like this part:

> ....
> Let's call this the "magical restful GET request".  It must appear exactly 
> as shown, with no additional body information, and no SOAP headers.  It is 
> an error to use the REST:GET element in any other context (if you study 
> the SOAP feature architecture, you'll find that it gives you away to 
> loosen this restriction in a controlled way later [4]). 

And I don't understand this part:

>...
> 
> * It is appropriately conservative in presuming that any additional in the
> information in the envelope might represent loss of safety.

If the message sender has declared that the message is safe then it is
not the infrastructure's job to make other decisions based on
heuristics. Most likely we would have to carefully consider the handling
of mustUnderstand headers.

>...
> What makes this proposal different from Tim's is that we don't start with
> a SOAP RPC envelope.  The mapping of method arguments into the URI is
> purely the business of the endpoints...the company name and date never
> exist in a SOAP body.  One way to do this would be with a WSDL convention:
>  mark the parameters that identify the resource.  The endpoint then knows
> to map them to the URI.  I'm not 100 percent sure this is a good proposal,
> but I think it's worth considering.

One concern I have is that your method calling API changes radically if
you are doing a "pure SOAP" method call, versus a WSDL-backed call,
because the WSDL-backed one has more information.

> ... Once
> again, this is correct REST, I believe.

One nit is that I am not entirely comfortable with my own promotion of
the term "REST" in the sense that I think its meaning is likely more
subtle than most of us understand. I think the goal of this part of our
discussion is to make SOAP fully URI-compatible.

 Paul Prescod

Received on Thursday, 25 April 2002 12:56:28 UTC