[OTDev] encoding accept header MIME types in URI
Vedrin Jeliazkov vedrin.jeliazkov at gmail.comTue Jan 11 13:34:28 CET 2011
- Previous message: [OTDev] encoding accept header MIME types in URI
- Next message: [OTDev] encoding accept header MIME types in URI
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [OTDev] encoding accept header MIME types in URI
- Next message: [OTDev] encoding accept header MIME types in URI
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Development mailing list