Dear Christoph, All,

On 11 January 2011 18:09, Christoph Helma <helma at in-silico.ch> wrote:

> Dear Nina, Vedrin,
>
> I guess we can agree that the canonical (and safest) way to specify the
> representation is to set the Accept header.


Definitely.


> 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
>
>
IMHO the latest (Accept) is much clearer to read, because it has explicitly
defined format, by means of standardized MIME.

I can agree curl commands will became more convenient with file extensions,
although I don't really perceive command line tools as   primary means for
using (any kind of ) web services, but this is a personal opinion.


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

Well, it's not an orthodoxy, but a design principle (meaning it's there for
a reason). An URI is an unique way to define an object, regardless of its
representation.   The representation is defined separately by the URI .  The
content negotiation by file extension is actually a patch for broken conneg
behaviour of browsers...



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

You are right, Restlet has support for content negotiation by file
extension, by setting

getTunnelService().setExtensionsTunnel(true);

and configuring extensions :

getMetadataService().setEnabled(true);
        getMetadataService().addExtension("sdf",
ChemicalMediaType.CHEMICAL_MDLSDF, true);
        getMetadataService().addExtension("mol",
ChemicalMediaType.CHEMICAL_MDLMOL, true);
        getMetadataService().addExtension("inchi",
ChemicalMediaType.CHEMICAL_INCHI, true);
        getMetadataService().addExtension("cml",
ChemicalMediaType.CHEMICAL_CML, true);
        getMetadataService().addExtension("smi",
ChemicalMediaType.CHEMICAL_SMILES, true);



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

Meanwhile, content negotiation by file extensions are enabled in ambit
services,  but some of RDF representations got contaminated by file
extensions and we'll need to spend more efforts on fully supporting file
extensions.

I am still concerned using file extensions is going to introduce a mess when
used in RDF. For example RDF/XML representation via
http://apps.ideaconsult.net:8080/ambit2/dataset/9.rdf  becomes

<rdf:RDF
...
  xml:base="http://apps.ideaconsult.net:8080/ambit2/">

 <ot:Dataset rdf:about="dataset/9.rdf">
    <ot:dataEntry>
      <ot:DataEntry>
        <ot:values>
          <ot:FeatureValue>
...

instead of

 <ot:Dataset rdf:about="dataset/9">

and the two URIs will be interpreted as different individuals by any RDF
library.

At least we'll need to agree URIs with extensions should not go into RDF
representation, and I am not sure at this moment there is an easy way to
ensure this in Restlet .

Best regards,
Nina


 Best regards,
> Christoph
>
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>