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

[Thomas Broyer]

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)?

>> Maybe you could explain how browsers do not conform to HTTP? (and no,
>> HTTP does not mandate user-agents to give the control of the Accept-*
>> headers to the user or the... server?!)
>>
>
> URI = Uniform Resource Identifier
>
> A given document available in html, pdf, xml - is one resource. The various
> content types are representations of that resource.

That's one way of looking at things, not *the* way (see below).

> 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".


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.

> Having to use a JavaScript virtual machine to perform PUT and DELETE is yet
> another example of this.

Conforming to HTTP does not mean supporting all of the defined methods
(even at the server-side: a server is free to return a 501).

>> There's an extension to HTTP (TCN/RSVA, RFCs 2295/2296) that gives the
>> servers the ability to describe the available variants of a given
>> resource in a content-type independent way. You'd rather push browser
>> vendors to implement TCN/RSVA than HTML5 to add a content-type
>> dependent equivalent.
>>
>> See also http://docs.google.com/View?docid=dggq7g95_10cd8zj5
>
> I don't really understand the point your making.. I would just like to see a
> way by which developers can link to *resources* with URIs and specify the
> representation if and when necessary for a given link.

So make another URI to identify that particular resource: "the same as
X but available only in format Y".

> There is no choice at the moment because HTML is insufficient.

I believe HTML is not in cause here (as any format with hyperlinking
feature would be "insufficient" too: as I said above: PDF, MSOffice,
OpenDocument, RSS, Atom, etc.)

>>> - I'll say it again: I'm encouraging you to help browsers become
>>> better HTTP clients; surely that is high on the agenda here.. right?!
>>>
>>
>> No, we're discussing HTML and some "Web APIs" here, not HTTP.
>>
>>
>>
>
> So the Transfer Protocol (HTTP) and the Markup Language (HTML) for Hyper
> Text are not closely linked?

No.
HTTP does not need HTML (WebDAV and CalDAV, for instance, do not need
HTML to work). and HTML does not need HTTP (aren't you sending HTML
mails yourself? and most documentation nowadays is in HTML format
stored on disk, without HTTP entering into play).
However, HTTP and HTML both make an heavy use of URI/URL.

>>> - separate versions are separate resources, not separate content types.
>>> That
>>> has nothing to do with conneg..
>>>
>>
>> s/version/variant/
>> Variants still need be produced by someone or something, and there
>> really might be discrepencies between them; that's why there's a
>> "quality" parameter in TCN/RSVA (and thus in Apache type-map files,
>> for instance)
>
> I'm not sure what you're getting at here. Multiple versions are multiple
> resources, they aren't seperate types so conneg is not appropriate. URIs
> handle this, the example I gave (which you left out) is proof of that.

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)?

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"?

How about an interactive animation you provide in both SVG+JS and
Flash. What if there's a bug the SVG variant (e.g. because of cross-UA
incompatibility)? They're the same resource, yet there can be
discrepencies between the two variants (and moreover in this case both
are directed to the same kind of UA: browsers, so you cannot even pick
up your favorite phrase "here's the animation, you can open it in XXX
or YYY")

-- 
Thomas Broyer