W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2006

Re: Thought of the day:

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
	high and variable latency generally OK
	low and stable latency often required
	sometimes required, sometimes not
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

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:28 UTC