On 11 January 2011 14:34, Vedrin Jeliazkov <vedrin.jeliazkov at gmail.com>wrote:

> Hi Christoph,
>
> 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
>
> These are somehow subjective qualifications (e.g. I don't think the
> extension approach is simpler or more intuitive than the other one).
> To add something more to the rant, IMHO introducing the concept of
> file extensions in some notorious OSes and applying various (sometimes
> even unspecified) semantics to it, has done more harm than good in
> many cases. Furthermore in the descendants of some of those OSes file
> extensions are hidden by default...
>
> >  - saves a lot of typing
>
> I guess you mean typing of curl command lines, right? If this is the
> case, we should also bear in mind that the end users would rather use
> some GUI which doesn't necessarily require additional typing in this
> case, while programmers have even more powerful methods to avoid it.
> So the burden would be only on testing things through curl or some
> other command line tools, which is not that much of an issue, after
> all...
>
> >  - downloads produce file names with correct extensions
>
> This is something that is nice to have, but I guess it could be done
> in both approaches anyways.
>

The correct way to assign filename and extension for download is to set
"Content-disposition" header in the HTTP response :

Content-disposition: attachment; filename=fname.ext

Nina

>
> > 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.
>
> Well, the resource <-> URI mapping wouldn't be straightforward in the
> file extensions approach. As you mentioned, you'll have to invent a
> new concept -- "base URI", with all the additional processing,
> required to keep track of it. Furthermore, this wouldn't be really a
> standard-based approach, so it doesn't have any advantage over the
> media approach in this respect.
>
> Kind regards,
> Vedrin
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>