Re: Hypermedia vs. data (long)

Mark,

Please see below.

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

Mark Baker <distobj@acm.org> wrote on 12/31/2002 03:16:42 PM:

> Whoa, long is right! 8-O
> 
> I'm gonna cut to the chase, if you don't mind.
> 
> On Tue, Dec 31, 2002 at 12:23:35PM -0500, Christopher B Ferris wrote:
> > The user agent is not concerned with whether the text/html 
representation 
> > of http://example.org/foo.html
> > is a representation of a resource about human anatomy, politics, a 
> > purchase order, or a description
> > of my car. All it needs to "understand" is text/html (well, 
technically, 
> > all it *really* needs to understand
> > is text/* since it can simply display/render the received HTML 
document as 
> > plain text and
> > let the human do the understanding of the HTML tags and the content 
that 
> > they markup).
> 
> For HTML, that's absolutely true.
> 
> But what if it were the "invoice" I described in my earlier example?
> That's not HTML.  It has no stylesheet specified that would be able to
> present it to a human.  It's meant *purely* for machine consumption.
> 
> To reiterate, what's the difference between;
> 
> GET <some-uri> returning some machine-processable XML document
> 
> and
> 
> POST <some-other-uri>
> <envelope>
>   <m:getInvoice/>
> </envelope>
> 
> returning the same document?

The problem in either case is you have no idea what you might receive
in response until you dereference the URI. Hence, you cannot have any 
expectation
that what you receive will be capable of being processed once received.

> 
> In both cases, what is returned is the same, so the human/machine issue
> is moot (which is why I'm not responding to your other points which are
> trying to show a distinction).  The only consideration is how the data
> got to the client in the first place, and I contend that the former is a
> superior approach by any measure.

I don't believe it is moot. I was NOT suggesting that GET is 
inappropriate.
The fact is that we added the GET MEP to SOAP1.2 HTTP binding. Again, that 
wasn't
the issue to which I was responding. It was the argument that you've been 
continuing
to harp upon, that all we need is in REST (and more specifically, that you 
contend
that all we need is HTTP).

> 
> > It is my belief that what you are hearing from many of us is that REST 

> > lacks a formal description
> > capability because it assumes mostly that the user agents will be 
charged 
> > with "understanding"
> > but a few select media types and that "understanding" is limited to 
> > rendering the representation,
> > typically for consumption by a human.  I do not believe that you are 
> > hearing us say "Links? We doan need no 
> > steenkin' links":)
> 
> URIs and GET are a low-coordination-cost way of retrieving data.  There
> is *NOTHING* human-specific about that.

Apparently, you missed my point entirely. I wasn't suggesting otherwise. I 
was stating
that it is not enough. Retrieving data is one thing. Doing something 
useful with it
once obtained is another. We are not at the point where our software 
systems can willy-nilly 
retrieve data without having a clue what form it might take before it is 
received.

REST is based on the premise that the agent receiving the data has but one 
responsibility;
to render it for (typically) human consumption. It is based on a limited 
set of standardized 
media types. It is low-coordination because the function of the user agent 
is simply to render
these standardized media types.

> 
> MB
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> Web architecture consulting, technical reports, evaluation & analysis