Dear Nina, Vedrin,

I guess we can agree that the canonical (and safest) way to specify the
representation is to set the Accept header. If we add methods to specify
the content type in the URI of the GET request it is purely for the
convenience of text oriented service consumers, e.g.

  - to create download links for websites
  - save typing for development and debugging
  - save typing for CLI nerds like me
  - create cleaner and less verbose code

As a lazy person (and one of the users who would benefit from such a
convenience method) I like notations that save typing without
compromising human readability (in program code and on the command line). 

curl http://webservices.insilico.ch/dataset/34.yaml

requires certainly less typing (and is IMHO easier to read) than 

curl http://webservices.insilico.ch/dataset/34?media=application/x-yaml

or

curl -H "Accept:application/x-yaml" http://webservices.insilico.ch/dataset/34

As a service consumer I do not care so much about REST orthodoxy,
implementation details and bad smells from a certain OS, although I do
not think, that these are real issues.

Extension based content negotiation is supported by many frameworks (I
think also Restlet) and common in REST services (I always had the
impression that it is a de-facto standard, because it is so frequent).
In our case empty Accept headers are rewritten based on the extension
and the extension is removed from the URI - our application does not even
see a difference between both methods of content negotiation.

It also fairly easy to implement extension based content negotiation
(remove the extension, look in mime.types for matching entries and set
the Accept header accordingly).

Best regards,
Christoph