[whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers

On Wed, Nov 19, 2008 at 2:22 PM, Mike <mike at mykanjo.co.uk> wrote:
> Thomas Broyer wrote:
>>
>> On Tue, Nov 18, 2008 at 11:52 AM, Mike <mike at mykanjo.co.uk> wrote:
>>
>>> Thomas Broyer wrote:
>>>
>>>> On Mon, Nov 17, 2008 at 6:31 PM,  <mike at mykanjo.co.uk> wrote:
>>>>
>>>>> - The HTML version of that URL could provide the web page
>>>>> representation
>>>>> *and* provide links to all the other content types available.
>>>>
>>>> How about other representations? (I know we're discussing HTML here,
>>>> and not HTTP, but what if a resource has no HTML representation? are
>>>> you proposing adding this capability to PDF, MSOffice, OpenDocument,
>>>> et al. too?)
>>>
>>> That's an issue at the application level; RSS would work fine in that
>>> situation - any form of hypermedia will serve that purpose.
>>
>> How would RSS work better than HTML (as of today; i.e. without your
>> proposed extension)?
>
> RSS wouldn't work better - you asked for another way of doing this without
> HTML, not a better way.

By "RSS would work fine" I understood that RSS link mechanisms already
match your "needs" in some way (which I know is wrong).

You're saying that HTML fails to provide a mean for controlling the
"message control data" to use Fielding's words (though restricting it
to the Accept HTTP request header field) and when I ask for how other
media types would work (or fail, actually), your answer is "RSS would
work fine".
You lost me.

>>> Because HTML is presently insufficient in providing a mechanism for
>>> browsers
>>> to perform protocol level conneg.. it's been moved into the URI and each
>>> representation is provided as a separate resource. This clearly breaks
>>> the
>>> intended definition of a URI - this is why I don't consider browsers to
>>> conform to HTTP; since they force developers to misuse that part of the
>>> protocol.
>>
>> If you want to precisely identify the PDF "version" of that document,
>> you need another resource (whose representations is a set with a
>> single value: PDF).
>> If your URI idenfies "this document", you cannot blame anyone but
>> yourself for not being able to identify "this document in PDF".
>
> If you want to precisely identify the PDF *representation* (version) of that
> *resource* (document), you need the URI and your Accept headers set
> correctly.

We're not reading the same definition for resource then...

"REST accomplishes this by defining a resource to be the semantics of
what the author intends to identify, rather than the value
corresponding to those semantics at the time the reference is created.
It is then left to the author to ensure that the identifier chosen for
a reference does indeed identify the intended semantics."
-- Roy T. Fielding, ?6.2.1 of his well-known dissertation

If your intention is to link to "the PDF version of 'some concept'",
then you need an URI to identify it.

> To that end, the solution to this problem would be to put
> example.com/document into a PDF reader. Or if you were writing an HTML page,
> and you wanted to indicate in the <a> tag that the browser should
> specifically request the PDF representation, you include an
> Accept="application/pdf" attribute.

How about other "message control data"? (other Accept-* HTTP request
header fields, but not only, as server-driven conneg is not limited to
those Accept-* headers)
And if WAKA <http://en.wikipedia.org/wiki/Waka_%28protocol%29> finally
make it one day, you'll have to amend HTML (and all other formats
where you added those things that you're proposing we add to HTML) to
take it into account.
(by chance, HTTP is one of the only "ReSTful protocol" --well, it's
just a protocol, you still have to follow the other ReST constraints)


>> Anyway, we're going real far from this WG's scope, so I propose we
>> follow up in private, or, even better, you re-hash the debate on the
>> rest-discuss list or with Roy T. Fielding if you want.
>>
>>
>
> I completely agree that discussion is outside of the scope of this WG. That
> is one of my main points here; It's a design decision that you are taking
> out of the hands of developers by not provisioning the mechanism for.
>
> I don't consider "well thats how its done and I don't think we need to do it
> any other way" an acceptable response, since it *is* outside of the scope of
> the WG and is a completely subjective standpoint. Not to mention that your
> opinion suggests that HTTP conneg has no "practical use", which I find hard
> to believe - feel free to explain why this is the case rather than just
> explain that it isn't used at the moment, I know it isn't!

Don't get me wrong, I'm all for using conneg when appropriate [1, 2]
and AFAICT the W3C uses it itself for its TRs.
Yet, I'm not saying "that's how it's done yada yada yada", on the
other hand I do believe that you are wrong considering hypermedia
consists of both a resource identifier *and* message control data.

[1] http://intertwingly.net/wiki/pie/PaceContentNegotiationSection
[2] http://www.imc.org/atom-protocol/mail-archive/msg05441.html

> OK.. Why would you not want to do everything you could to support all of the
> aspects of HTTP, particularly when you are being given a solution that
> allows for backwards compatibility.

Because the next one will want a similar support for some other protocol too.

>> So make another URI to identify that particular resource: "the same as
>> X but available only in format Y".
>
> That's conneg in URIs.

No, that's agent-driven conneg (and in this case even user-driven). If
you propose several options to the user for it to pick one, then
choosing server-side conneg and trying to control the request's
"message control data" is a Bad Idea.
It's like showing a wood stick and a ball to a dog, asking it to
choose one and yet refusing it to point at it: "no Rex, don't pick the
one you want, rather tell me the one you want and I'll give it to
you".

> I'm not saying that you cannot achieve conneg in URIs, I'm simply pointing
> out that another approach is the make use of protocol level conneg and avoid
> creating new URIs for every resource representation. I'm not even claiming
> it's a superior approach; it's just a valid alternative that makes proper
> use of the conneg provided in HTTP - HTML could support this approach by
> implementing my proposal.

But other hypermedia technologies wouldn't and would have to be
changed too: XLink, MSOffice, PDF, Atom, RSS, etc. *and* clients would
have to take those changes into account too.
This is not realistic.

> HTML is a hypermedia. Hypermedia are special case formats that should allow
> UAs as much as possible to make best use of HTTP.

Why? How is hypermedia limited to HTTP? (hypermedia was 20 years old
when HTTP and the Web was born)

> One of the examples you
> gave was Atom, which is going to great lengths making amendments to support
> the HTTP protocol - for that very reason.

Which amendments are you talking about ?!


>> Let me try again: your document is available in HTML and PDF (let's
>> keep it simple). Who makes the HTML? Who makes the PDF? How can you be
>> 100%-sure that both variants are strictly "identical" (if ever they
>> can)?
>
> If they aren't identical; they aren't the same resource - and it would be
> idiotic to serve them from the same URI.

If the both "represent the same concept", why cannot they be the same resource?

And actually, a PDF and an HTML variant of the same resource are most
likely not identical, as:
 - the HTML variant will probably load external images while the PDF
variant will embed them;
 - PDF allows for vector graphics while HTML defers it to another
format (such as SVG) that might not be embeddable and for which you
might want to provide a rasterized alternate;
 - the PDF variant might use a three column layout
 - the HTML variant might "try" some complex layout if supported
(using CSS3 grid positionning, or CSS3 multi-column layouts) and
fallback to a simpler one if not; not even talking about CSS hacks
 - etc.

>> Let's consider the famous "SVG tiger" image, that you would make
>> available in both SVG and PNG. Isn't the SVG qualitatively better than
>> the PNG? Aren't they the same resource "sketch of a tiger"?
>>
>
> 'Better' ? I don't understand the point your making here..
>
> What are your criteria for this judgment?

Quality.

> What if I think smaller file size is 'better'?

I talked about better *quality*. As soon as one variant is derived
from another one, there's a potential loss in quality. And even in the
case variants are not derived from one another, some media types are
more "expressive" than others and can be said of "better quality"
without being subjective: a quote of the day resource served as
text/html and text/plain: text/html can markup the author (<cite>) of
the quote (<q> or <blockquote>); if an UA doesn't mind between
text/html and text/plain, the server would probably send it text/html
because it is more expressive, hence of "better quality".


And I'll stop here (unless you bring another argument), I've spent
more time than necessary in this debate.


-- 
Thomas Broyer

Received on Thursday, 20 November 2008 01:12:29 UTC