One more post on REST and then I am done: (was: WS-Addressing and R085)

-----Original Message----- 
From: Mark Baker [mailto:distobj@acm.org] 
Sent: Mon 4/14/2003 17:19 
To: Clemens F. Vasters 
Cc: www-ws@w3.org 
Subject: Re: WS-Addressing and R085

Hi Mark,

>Consider a description of a book;
>
><book>
> <title>Some book</title>
><author>Some author</author>
></book>
> That is not a message. 

Right, but that here is:

<insertbooks>
  <book>
    <title>Some book</title>
   <author>Some author</author>
  </book>
</insertbooks>


>But you just said you "write a booking record into a financial collections
>system".  That is easily representable as a resource-access action.

Because of scheduling constraints this will likely be my last big post on this issue. I'll simply say what I think needs to be said from my end. Therefore, I will apologize ahead of time for being probably a bit too blunt here. 

If you want to make my example look like it's perfectly okay with REST, that's great. However, you are confusing data, message, endpoint, objects, services, identifiers, state and other things and make a big mess out of them. You seem to twist and turn things as you think they fit to keep your point of "REST being a universal archtecture principle" alive. 

So, how can a resource be defined as a universally locatable data bucket one time (http://www.contoso.com/accounts/2627272), that I can GET, POST, PUT and DELETE on and another time just as "a service" (http://www.contoso.com/submit_bookings_here) <http://www.contoso.com/submit_bookings_here>  and another time maybe something that's more like an object? How is that consistent? How is that service, which will just chew up the input data, a "resource"? It'll give you exactly nothing when you go and GET something from it, because it has nothing to give you? It'll not be able to do anything with a PUT or a DELETE. The only thing it understands is a chunk of data flowing in. 

Many people think about web services as a way to integrate business processes. Business processes are pure message flow. No GET, no DELETE, no PUT. Data goes into an endpoint and other data comes out of a different endpoint. Application protocol? Thanks, no need: overhead.

So, when is something behind a URI a service? When is it a resource? When is it an intermediary? When is it an object? When is a piece of data uniquely identifiable? When isn't it? What's an instance? Do instances exist? How do I deal with multiple non-clusterable endpoints with different URIs for the exact same piece of replicable data? Are there singleton services? Are there resource-restricted services? How about multi-hop routing, idempotence, transactions, scheduled messaging, batching and reliable messaging in that world? 

If architecture-style doesn't mean "well-defined" but rather "oh, whatever you choose, it can be any of that and it's sometimes even something else" all of that goes squarely against the little bit of German engineer that I have left in me. So I rather say "a URI uniquely identifies an endpoint I can send messages to" and I am not speaking of a mix of services, data, messages, resources and other things. 

Also, you insist on a distinction of transport and application protocols that only very few people care about. For 98% of all people you'll ask out there at any conference (and I am at very many of those), HTTP *is* a transport with GET, PUT and POST being unfortunate implementation details and it doesn't matter whether you or I know better. Because HTTP is as pervasive as you say, it's as misunderstood as you lament.

What's very unfortunate is that you didn't address my point about scalability and I will happily quote myself:

"So, getting to the heart of the problem, which is "I want to use HTTP, because it serves billions very well": True, but that particular protocol is only used at the surface. Once the data makes its way into the core of systems, one-way messaging pipelines, content based routing and batch processing rule the place. HTTP is a nice gatekeeper. I would argue that neither Amazon nor Google nor Hotmail scale because they're using HTTP -- even quite to the contrary. "

And I didn't see you saying anything about the impossibility to unlink transport from application protocols

"Lastly, I have a hard time seeing how one can achieve the required transport independence given a pre-defined application protocol that is layered on top of -- at the very least -- a set of assumptions about transport (such as bidirectionality)."

Mark, I have tried to make sense out of what you are saying, but for the problems I have been faced with in the past and the ones I am thinking about right now, very little of that makes sense to me. You said on your weblog a while ago that we may have to rethink things like transactions or reliability. Yes, we may, but until someone starts and finishes that new thinking, I rather stick with the things that we have. I've got work to do and to help build solutions. Now. Maybe it's just me. 

Lastly, isn't it funny that the world has probably spent hundreds of billions of U.S. Dollars on HTTP infrastructure over the past ten years or so and we're still having this discussion? Isn't it ironic that likely not a single dollar of that money has been transfered between the world's banks using HTTP?

Regards,
Clemens

Received on Tuesday, 15 April 2003 04:04:18 UTC