RE: TAG document: SOAP HTTP GET binding available

 Hello all. 8-)
 I've just finished reading all the email about SOAP, REST, HTTP, 
the GET binding, its relation to WSDL etc - a few hundred 
messages. Therefore I apologize if I missed some important 
detail and if this is too late to respond.
 I'm a member of the XMLP WG. At first, I was a complete 
tunnelist, not understanding that HTTP is an application 
protocol based on REST architecture. I was educated mainly by 
Mark Baker in various discussions.
 Granted, I'm rather inexperienced in these matters, but I think 
I may have a view here that hasn't been discussed extensively 
here (if at all).

 My current understanding is that REST is the architecture of an
application named WWW and HTTP is the main one of its protocols, 
directly mapping to REST.
 SOAP on the other hand is a message protocol with some semantics
allowing extensibility. It might be compared to UDP, I think. It 
needs a transport protocol underneath it, like UDP has IP. A nice 
binding for SOAP would be a TCP binding.
 Now *over* SOAP with a Request/response message exchange pattern
we can build applications. One of these could be REST/SOAP, with
four different possible body contents - rest:Get, rest:Post,
rest:Delete, rest:Put, with any data inside.

 Compared to HTTP:

 mechanism      |     HTTP      |    SOAP
----------------+---------------+--------------
 method		| on first line | only child of Body
 data           | entity body   | children of the above
 metadata       | headers       | children of Header

 If there is anything I've missed, I believe it would map as 
straightforwardly.
 I think this REST/SOAP application is an extension of Noah's
proposal for the magic Get request mapping in the HTTP binding to
HTTP GET.

 The HTTP binding in SOAP needs to act as the transport protocol
beneath SOAP. Therefore no RESTisms should be allowed (HTTP 200
OK for faults, POST-only for example), but also the whole binding
should be viewed as very suspicious - misusing an application 
protocol for a transport protocol. This should not be a part of a 
W3C recommendation.
 On the other hand there could be a specialized SOAP binding to 
HTTP, only for the REST/SOAP application outlined above, choosing 
the HTTP method based on the Body child, possibly mapping SOAP 
headers to HTTP headers (IMHO the details should be handled by 
the extensions themselves - they should provide a SOAP header 
and HTTP header so that the mapping is trivial).
 RPC, that's an application, too, or somewhere between a
transport and an application, so RPC should not be done over
REST. And therefore the specialized HTTP binding should not be
used for RPC.

 So my conclusions are:
 * SOAP HTTP binding tries to be two bindings at once, failing on
both sides.
 * A general SOAP HTTP binding should not be done, in recognition
of the fact that HTTP is an application protocol. Also, the 
current SOAP HTTP GET binding would be dismissed.
 * A specific SOAP HTTP binding for REST/SOAP can be done at the
same time as REST/SOAP itself is specified, and by the same
group.
 * XMLP WG should provide a less problematic transport binding,
probably to TCP (or other such transport protocol - I don't know
where DIME stands, I also don't know how people view the email
framework - if it can be a good message transport protocol
underneath SOAP).

 Practically, this should not hold off the XMLP Last Call but it 
can be a very important comment in that phase and, if the TAG 
issues such comment, it could well cause the XMLP WG to issue a 
second last call with new bindings.
 Granted, *lots*of*education* would need to be done in order for 
this new SOAP to get any attention from the world, without the 
generic HTTP binding. I think REST/SOAP (with its HTTP binding) 
could ease this phase considerably.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/

Received on Tuesday, 14 May 2002 07:34:02 UTC