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

[Mike]

Thomas Broyer wrote:
> On Mon, Nov 17, 2008 at 6:31 PM,  <mike at mykanjo.co.uk> wrote:
>   
>>> Would the sender of that link necessarily know all the formats the URL
>>> provides?  Anyway, that's an unrealistic amount of typing -- typically
>>> round here people just copy and paste a URL into an instant message
>>> and send it without any surrounding text.
>>>
>>> Whereas without any other information, people will generally open URLs
>>> in a web browser.  So it'd be faster just to send the URL of the page
>>> which contains hypertext links to all the formats; at which point we no
>>> longer care whether those links specify the format in the URL or
>>> elsewhere.
>>>       
>> - 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.
>   
>>> What is the point of doing it in HTTP if it's being done in HTML anyway?
>>>       
>> - Nothing is 'done' in HTML, it's a markup language. It's being done (at the
>> moment) in the URI. HTTP provides conneg, why would you consciously
>> deny developers the opportunity to use it in browsers? Unless HTML5
>> provides the markup, this isn't possible. This means Browsers don't have
>> the ability to fully support HTTP without having to use JavaScript rubbish;
>> there is a window of opportunity to change this with HTML5.
>>     
>
> No. Browsers fully support HTTP in the sense that they send an Accept
> header dependent of their *capabilities*.
> If you want client-driven conneg, then use agent-driven/transparent
> (RFCs 2295/2296), not server-driven conneg. This is explicitly noted
> in RFC 2616 that server-driven negotiation has limits and can be
> disadvantageous depending on your needs.
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html#sec12
>
>   

My argument is to provision both and let developers decide.

>>> True.  But if the current way of doing it is good enough, there's no
>>> incentive to change."
>>>       
>> - Define 'enough'..! I don't know why/how you get the authority to
>> make that assumption! And before you say it; I'm not assuming any
>> authority myself - I'm trying to encourage you to help browsers conform
>> to the protocol they make use of.
>>     
>
> 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.

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.

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

> 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. There 
is no choice at the moment because HTML is insufficient. An optional 
Accept attribute would address this issue and still allow for the 
current methods that you feel (subjectively) are 'sufficient'.

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

If you aren't discussing it that way; it might be worth considering, no?

>>> Or what about if I wanted to mail somebody pointing out a discrepency
>>> between two versions of the report, and wished to link to both of them.
>>> That's tricky if they have the same URL.  Possibly I could do it like
>>> you have with the wget command-line above, but that requires me knowing
>>> which browsers my audience use and the precise syntax for them."
>>>       
>> - 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.

Regards,
Mike