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

[Mike]

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.

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

If you want to precisely identify the PDF *representation* (version) of 
that *resource* (document), you need the URI and your Accept headers set 
correctly. 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.

Does that not count as a use case for this proposal? Perhaps not, if you 
believe that content negotiation belongs in the URI. This is a design 
descision, and I believe that developers should be allowed to make this 
descision at design time. Currently there is no standard in HTML to do 
this; hence why I have proposed this optional Accept attribute. To give 
the option and make it feasible to use HTTP content negotiation in web 
applications.

I am yet to be provided with an example of where this addition could 
cause any problems, so I don't understand the apparent resistance to 
this; since it is clearly a valuable addition which enables HTTP conneg 
in browsers.

> 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!

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

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. I don't mind getting involved 
and doing the work on this myself, if that means this will happen.

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

That's conneg in URIs. It should be reasonably apparent that I am aware 
of this technique by now; I think the original post I made even said as 
much!

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.

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

HTML is a hypermedia. Hypermedia are special case formats that should 
allow UAs as much as possible to make best use of HTTP. 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.

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

HTML is the standard markup used for provisioning HTTP application GUIs. 
If HTML only supports conneg in the URI.. guess what web application 
developers do.. conneg in URIs! There is presently no alternative, so 
there are very few web applications that use the alternative protocol 
level conneg.

HTML is a markup, it doesn't make use of URIs - it indicates to clients 
how to make use of URIs. Totally different thing.

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

If they aren't identical; they aren't the same resource - and it would 
be idiotic to serve them from the same URI.

> 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?
What if I think smaller file size is 'better'?

If the image represented in both formats is the same; they are the same 
resource. My interpretation doesn't make you wrong, and yours doesn't 
make me wrong. The only difference here is that my approach is currently 
totally impractical because HTML provides no way of doing this 
contextually within browsers.

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

Provided the animation is the same - the only discrepancy is the 
representation of that animation (i.e. the content type).

Again, the case you have raised here is another important point; which 
is that browsers handle alot of different content types and it depends 
on the particular HTML page as to which representation you would want 
the browser to display.

If you were insistent as a developer that only the flash representation 
of the animation was only appropriate on a particular page; then you 
*could* achieve this *if* your tag containing the reference to 
example.com/animation had the attribute 
Accept="application/x-shockwave-/flash/".

Or if you were happy that the browser could decide, you would leave the 
tag off and let the browser send it's default Accept header - this is 
probably the most likely case in this instance because both 
representations render identically and are embedded so there's no real 
incentive, in this particular case, to specify over the browser 
defaults. Obviously if we are talking whether a link to 
example.com/report returns a pdf or a word document - this is a 
different use case.

I hope this has cleared up my position for you, if you still disagree 
let me know - I dont think there's any reason to continue this in 
private since this is all relevant information to the discussion - I 
have no intention of debating with you over whether HTTP conneg is 
superior to conneg in URIs or not, I just think both should be 
provisioned for.

Regards,
Mike