- From: He, Hao <Hao.He@thomson.com.au>
- Date: Sat, 24 Jan 2004 00:16:55 +1100
- To: "'Michael Champion '" <mc@xegesis.org>, "''www-ws-arch@w3.org ' '" <www-ws-arch@w3.org>
- Message-ID: <686B9E7C8AA57A45AE8DDCC5A81596AB0922DF81@sydthqems01.int.tisa.com.au>
Good we are not putting the text into the document. A number of points: 1. The URI is just an identifier and it is not a message carrier (except the query part) so one does not encode the whole SOAP message. You either POST the message or the URI of the message so others can GET it. 2. If you want complex REST and transaction-oriented example, we have built typesetting systems that we use to publish books, those real complicated books for professionals. 3. Using SOAP does not mean it is non-RESTful. However, if one wants to use it in a non-RESTful (RPC) way, one really needs to justify it. 4. What is the architectural significance of SOAP after its moving away from the role of RPC encoder? Hao -----Original Message----- From: Michael Champion To: 'www-ws-arch@w3.org ' Sent: 1/23/2004 11:02 PM Subject: Re: Section 1.6 and REST - Can we make this more clear and useful ? On Jan 23, 2004, at 6:35 AM, He, Hao wrote: > I strongly oppose the text because it does more harm to the document > than > good. I don't have any particular desire to put this in the document. I'm stating my personal views using Roger's expression of his view as a starting point. The very LAST thing I want to do is reopen the REST debate if it is divisive; the point I took from the discussion yesterday was to find a *useful* way to summarize what we learned from the debate. > > > SOAP is a specific technology. One can use it RESTfully or > non-RESTfully. > If one uses it RESTfully, one gets the nice architectural properties > such as > reliability, scalability, extensibility, etc ... . If one uses it > non-RESTfully, one has to prepare for the aftermath of tight coupling > (the > old wonderful world of distributed objects). I pretty much agree (although I'm not particularly happy by saying that the alternative to REST is "distributed objects." But we've never managed to come up with a good term for "non-REST". > > In short, saying that REST is only useful for simple applications, is > totally misleading. > Well, I think this is the crux of the matter. I don't see any example of Web services as we define them, or "SOA" as the analysts and marketers (and several of our companies!) are using the term, that use REST in a complex way. Maybe we will; I wouldn't be surprised, but I want to see the proof before putting my own credibility on the line. Anyway, this is where I come down (personally, not necessarily what I want the WSA document to say): REST is demonstrably useful and efficient for straightforward, information-oriented, Web-based automated services. Amazon is a real world example; their RESTful interface for programatically looking up information on books is quite a bit more popular than their SOAP/WSDL distributed object API. Beyond that, I just don't know of compelling examples, and the lack of a support for doing much with SOAP for requesting data in a RESTful way seems like a show-stopper for using REST in a multi-network, high-security, transaction-oriented manner. (I'm referring to the fact that there's no obvious way to encode a complex SOAP message in a URI). Bottom line: REST is a tool that Web services / SOA developers should know how to use and when it can be used most effectively, but not treat it as a philosophy to be applied whenever a distributed system needs to be built. (That message seems to go over well with the audiences I speak to on this subject) As for the WSA document, I'm reasonably happy with what we say in the current draft. Roger thinks we can put in more clear and useful language summarizing what we think about REST. I'm sure that each of us as individuals can do so, but I doubt if we can get much clearer than the current document text and maintain a consensus. But I said I'd try :-)
Attachments
- text/plain attachment: InterScan_Disclaimer.txt
Received on Friday, 23 January 2004 08:14:20 UTC