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

[Martin Atkins]

Hallvord R M Steen wrote:
> 
> I've built two-three websites that use content/language negotiation
> and I now consider it an architectural mistake to rely on negotiation
> because the URLs no longer uniquely identify the variants I in many
> scenarios need to identify. It's OK-ish to do it as a pure format
> choice where the server and UA just agree on using the PNG or GIF
> version for an <IMG> tag. For links *users* (and FWIW search engines,
> validators and other agents) may interact with it's however a big
> mistake to move away from one URL per variant of a resource. In light
> of my content negotiation experiments and experience I'd say an Access
> attribute in HTML would be harmful to the usability of URLs.
> 
> As a URL user (web browsing human, HTML author, linker, bookmarker,
> E-mail-with-links author) I often want to be sure about what variant
> of a resource I link to. To be explicit about this across scenarios
> requires explicit URLs with language and type information.
> 

Agreed. I think the assumptions underlying content negotation are 
flawed, and thus the mechanism itself is flawed and causes confusion and 
inconvenience when used in practice. The sentiment underlying this 
proposal seems to be that HTTP content negotation would work fine if 
only the pesky browsers would support it, but I think there are 
deeper-rooted problems than simply a lack of browser support.

I think a better solution is to publish the HTML version with attributed 
hyperlinks, like this:

<link rel="alternate" type="application/pdf" href="document.pdf">

or, if you prefer:

<a href="document.pdf" rel="alternate" type="application/pdf">
     PDF Version
</a>

This way clients can discover the alternative representations, but the 
alternative representations are all directly addressable so you can link 
to a specific representation. This approach is used in practice 
successfully today to make available Atom representations of HTML pages 
across the web. Atom feeds are arguably the best example of a successful 
  completely-RESTful API that we have today, so this approach is proven 
to work.

In future, once IETF has finished specifying this, it may also be 
possible to do this in the HTTP response headers for non-HTML resources:

Link: <document.pdf>; rel="alternate", type="application/pdf"
(or something similar)

...and some other document formats such as Atom already provide 
equivalent linking constructs that you can use today.