- From: Paul Prescod <paul@prescod.net>
- Date: Sun, 16 Jun 2002 13:50:12 -0700
- To: Jacek Kopecky <jacek@systinet.com>, "xml-dist-app@w3.org" <xml-dist-app@w3.org>
- CC: Mark Baker <distobj@acm.org>
Jacek Kopecky wrote: >... > If we agree on the high goal above, I believe we should not > produce an HTTP binding of SOAP at all, or as a secondary binding > for limited use in REST-based applications; the main binding > being a transport protocol (TCP or other) binding. We've agreed on this issue before Jacek. Running SOAP on TCP would certainly be the more conventional and in many ways the more productive way to go about this. But I'm not the person you must convince, that is the others in xml-dist-app and the wider world. To be honest, I doubt you will have much luck. The point of us REST-ians is: "*If* you produce an HTTP binding it must capture the semantics of HTTP as much as possible." That is an urgent project because once the binding is deployed, it is deployed and if people are abusing HTTP there will be damage to the Web infrastructure as we saw with the Google example and its "missing URIs." A less urgent project is to re-invent a REST-ful prototocol on top of SOAP. In my opinion, this should have been a SOAP use case from the start (as XHTML was an XML use-case). But it was not and now SOAP is not particularly well suited as a protocol basis for the Web. In particular it has poor handling for binary data. The web transports gigabytes of non-Unicode data every day. Until SOAP has an efficient, standardized solution for that issue, it is not an appropriate foundation for the Web of the future. That is a pity. Paul Prescod
Received on Sunday, 16 June 2002 16:50:24 UTC