- From: David Hull <dmh@tibco.com>
- Date: Tue, 10 Jan 2006 11:45:01 -0500
- To: Mark Baker <distobj@acm.org>
- Cc: xml-dist-app@w3.org
- Message-id: <43C3E48D.5080008@tibco.com>
Mark Baker wrote: > Yup. REST is suited for relatively large messages; like SOAP > messages, for example. 8-) > That's like saying that a hockey stick is good for stirring a drink because ice is involved in both cases. Here's a fuller comparison. I've mentioned at least some of these factors before without hearing any dispute: Hypermedia Transfer Messaging Latency high and variable latency generally OK low and stable latency often required Reliability required sometimes required, sometimes not Topology client-server peer-peer Object size (*) KB to at least tens of MB tens of bytes to tens of KB (*) This is more subjective than the other items. It's certainly logically possible to send a GB message or retrieve a completely empty document. Nonetheless, messaging tends not to deal in larger data sizes that are routine if not prevalent in hypermedia applications. It seems at least conceivable that the two domains might require different approaches. Further, SOAP is useful in either domain. If anything, it should be more appropriate to messaging, since the SOAP processing model is centered around sending messages from node to node. This is why it's perfectly appropriate for XMLP to discuss one-way messaging, particularly in the context of protocols like XMPP and BEEP, but also in the context of HTTP. If the results are not completely RESTful, that's no surprise. REST is playing -- very well -- in a different space. Being oriented toward Hypermedia Transfer, HTTP is naturally not the best fit for messaging, but it can still be useful in situations where latency is not a concern and topology is not an issue, whether because there are only two nodes involved or because the HTTP exchange is part of a larger picture. Again, this is perfectly appropriate. HTTP is being used to transfer data, in accordance with the HTTP specifications and without breaking any existing or future infrastructure. No harm, no foul. If I've missed something and some scenario I've put forth breaks, please state specifically what breaks and how. So far I haven't seen that. I've seen much made of the assertion that HTTP doesn't allow HTTP responses to come back out of order, but no one's stating otherwise. > > Mark. > > On 1/9/06, David Hull <dmh@tibco.com> wrote: > > > > "The REST interface is designed to be efficient for large-grain > > hypermedia data transfer, optimizing for the common case of the Web, but > > resulting in an interface that is not optimal for other forms of > > architectural interaction." -Roy Thomas Fielding, "Architectural Styles > > and the Design of Network-based Software Architectures", Chapter 5. > > > > > > > > > -- > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca > Coactus; Web-inspired integration strategies http://www.coactus.com >
Received on Tuesday, 10 January 2006 16:45:13 UTC