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.

> 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