RE: Hypermedia vs. data (long)

The difference is that in the first case
> GET <some-uri> returning some machine-processable XML document

you have a URI that refers to the specific invoice instance. (which assumes
that the client has received this invoice URI somewhere along the line)

In the second case (which would probably look something a bit more like
this)
> POST <some-other-uri>
> <envelope>
>   <m:getInvoice>
>      <m:invoiceID>...</m:invoiceID>
>   <m:getInvoice/>
> </envelope>

the URI probably doesn't refer to an specific invoice instance, and in this
case you would probably need to specify the invoice number (or some other
identifier) as an input parameter. If you aren't passing any input into the
service, I can't imagine why you would want to use the POST message to
request an invoice (unless you need to pass SOAP header info, such as
authentication information).

So, next I ask, if you have a URI to represent this specific instance of an
invoice, why would you want to return the XML document within a SOAP
envelope? Why not just return it as an XML document? (aside from security
reasons -- e.g., I want to sign the document, etc -- although I don't need a
SOAP envelope to send you a signed document).

Anne

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Mark Baker
> Sent: Tuesday, December 31, 2002 3:17 PM
> To: Christopher B Ferris
> Cc: www-ws-arch@w3.org
> Subject: Re: Hypermedia vs. data (long)
>
>
>
> 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?
>
> 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.
>
> > 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.
>
> MB
> --
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> Web architecture consulting, technical reports, evaluation & analysis
>

Received on Tuesday, 31 December 2002 15:49:15 UTC