Re: A REST challenge

David Orchard wrote:
> 
> Paul asked a question about how one would do correlation in SOAP...  Well -
> aside from a small tech problem with 3 versions being retrieved :-( - we've
> got something at http://ftpna2.bea.com/pub/downloads/SOAPConversation1_0.htm
> 
> We can talk about implementation experience rather than theory.

I'll point out that correlation using URIs is also done commonly in the
real world. Since that URI is a 404 perhaps you could give some concrete
syntax examples of what you propose.

> There's a very important debate going on here, specifically about the
> utility of URIs as a data format, versus the use of XML.

I think that it is more precise to say "utility of URIs as an
identification format."

> In the SOAP Conversation spec, XML is used to define the conversation ID
> separately from the callback-URI. 

As far as I know, there is nothing about REST that disallows a
conversation resource. For instance a conversation resource is a
perfectly valid concept in an instant messaging application.

You could certainly do this in a REST system also, if there is a
concrete benefit to it. After all, all you need is a "conversation ID"
header. If you want to be 100% REST-y then you should reify the
conversation as a resource and use a URI to it.

The problem as stated did not need a concept of "conversation" and it
did not seem useful to add it. So we didn't.

> .... So the XML extensibility model is
> utilized.  You can imagine doing exciting things like adding security
> information - when calling back, use this particular security token - and
> others to the XML model.

Sure, we do that stuff with REST/HTTP all of the time. All REST says is
that you don't invent some non-standard conversation ID concept. If you
need to reify conversations then make them URIs and allow both parties
and third parties to inspect them using standard tools. According to the
TAG:

"An important principle of Web architecture is that all important
resources be identifiable by URI."

I'm sure you'll agree that a conversation is an important concept. If it
is, then it should be a URI-addressable resource. Furthermore, it should
be addressable by HTTP so that it is inspectable and introspectable
using GET. 

> If everything related to the resource identification is ALWAYS munged into
> the URI, then it is harder to extend the model for new interface features.

Resource identification is always done using URIs on the Web. That's
what makes them Uniform and Universal.

> URIs have a hierarchical notion - ie. correlation/security/some other
> stuff - whereas XML allows us to have a much more expressive content model.

To me, that's a little bit like complaining that Intel's pointers have
only 32 bits whereas XML is much richer. You can use *pointers to XML*
and URIs *to XML* when you need structure.

> IMHO, the difference between wanting to use XML's capabilities for
> expressing information versus the URI data model is perhaps the core of the
> debate.  The REST folks believe that you have to use URIs and HTTP (AND ONLY
> URIs and HTTP) for everything necessary to access the resource, and others
> think that XML is a fine extensible format for encoding information about
> resource access, and it even works over other protocols.  

We all agree that XML is a fine extensible format for encoding
information "about resource access" (e.g. authentication or even
correlation information). Where we disagree (to be folksy) is that REST
people believe that the Web already has a resource *identification*
mechanism and inventing other ones is no more productive than inventing
your own "33bit" pointer on X86 rather than using the native pointer
understood by all the other operating system components. Using the
standard buys economies of scale and costs nothing because pointers are
just, well, pointers and there is no reason to have both standardized
and proprietary syntaxes for them.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/

Received on Tuesday, 16 July 2002 19:17:06 UTC