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

> On Tue, Jan 11, 2011 at 01:24:45PM +0200, Nina Jeliazkova wrote:
> > >
> > > Well, I don't like the extension approach at all,  because it is not
> > > aligned with the REST idea that an URI is one resource, having
> different
> > > representations.   Adding extensions means these are effectively
> different
> > > resources , and have different URIs (even it will be hard to tell
> within RDF
> > > representation these are the same objects!)
> > >
> > > URI parameters are little bit better (not ideal), in the sense the URI
> is
> > > still the same.
> > >
> > >
> > One more argument against extension came to my mind after sending the
> email
> > - it will make AA much more complicated,  as we'll have to register
> multiple
> > URIs about the same object into OpenSSO system ...
> >
>
> From a user/client point of view I would prefer the extension approach,
> because it is
>
>  - simple
>  - intuitive
>  - saves a lot of typing
>  - downloads produce file names with correct extensions
>
> I do not see a contradiction to REST priciples as extensions are just
> another (commonly used) convention to specify the mime-type.
> Internally the services should work of course with the base URI (e.g.
> for AA) as the extension indicates another format, not another resource.
>

Distinguishing between base URI and an extension is exactly the violation of
REST principles, where one URI is identifying an object.  There is no notion
of "extension" in the HTTP protocol at all, these are different URIs (and
will be  recognized as different URIs by all systems, except let's say
customized OpenTox web services.

Last but not least, how does one distinguish between an extension and a
valid URI, containing a dot ? e.g. http://host/compound/CCC.CC ?

I think URI parameter is so much easier for everybody and doesn't require
any additional effort (parsing URI parameters is already done for other
reasons and supported by all frameworks).

Best regards,
Nina


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