[OTDev] encoding accept header MIME types in URI
Luchesar V. ILIEV luchesar.iliev at gmail.comThu Jan 13 08:07:36 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 ]
On 01/11/2011 13:24, Nina Jeliazkova wrote: > On 11 January 2011 13:19, Nina Jeliazkova <jeliazkova.nina at gmail.com> wrote: > >> >> >> On 11 January 2011 13:15, Martin Guetlein <martin.guetlein at googlemail.com>wrote: >> >>> On Tue, Jan 11, 2011 at 11:38 AM, Nina Jeliazkova >>> <jeliazkova.nina at gmail.com> wrote: >>>> Hi Martin, >>>> >>>> On 11 January 2011 12:13, Martin Guetlein < >>> martin.guetlein at googlemail.com>wrote: >>>> >>>>> Hello all, >>>>> >>>>> is there a standardized way to encode MIME types in URIs instead of >>>>> using the accept-header? >>>>> >>>>> For example Ambits services allow to specifiy this via 'media' >>> parameter: >>>>> >>>>> >>> http://apps.ideaconsult.net:8080/ambit2/compound/4025/conformer/462030?media=image/png >>>>> @Nina >>>>> How did you decide to use 'media'? >>>>> >>>> >>>> This is an (optional) support by Restlet library. There is so-called >>> "Tunnel >>>> service" , which could be turned on (off by default) and will accept >>> "media" >>>> parameter to specify MIME type. >>>> >>>> There is also "method" parameter, allowing to "tunnel" all HTTP methods >>> via >>>> GET. (e.g. curl -X GET /dataset/999?method=DELETE ) >>>> >>>> >>>>> Have other partners implemented something similar? >>>>> >>>> >>>> I guess it is easy for all partners using Restlet to turn the tunnel >>> service >>>> on. >>>> >>>> AFAIK, there is no standard solution for this kind of workaround. If >>> there >>>> are no preferences from other REST frameworks , we might decide to >>> include >>>> "media" parameter in the API as well. It is quite convenient to >>> "deceive" >>>> browsers ... >>>> >>>> Best regards, >>>> Nina >>> >>> >>> Hi Nina, All, >>> >>> I just discussed this issue with Christoph, Micha and Andreas. >>> Even though the media parameter is already integrated in Restlet, and >>> could be implemented for our framework, we thought about another >>> solution: >>> We could use file-extensions in URIs, i.e. add ".rdf", ".txt", ".png" >>> to the resource URI. >>> This would need slightly more effort in terms of implementation (map >>> file-extensions to MIME types), but would be very intuitive and easy >>> to use. >>> >>> What do you/people think? >>> >>> >> >> 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 ... I'd like to reiterate this one. And it's not just about increased complexity; it's even more about increasing security risks. What happens if you add a new representation for a resource, for example? Security-wise, at least in the REST context, that would indeed be a different resource, and it would therefore require its own policy. It could (and most likely would) be the same as that of the other representations, but the service that creates it should obviously do all the required legwork, with enough places to mess something up. Now, as I've said that, it also becomes evident that using extensions could provide way to define _different_ access restrictions to different representations, and one that is rather easy to implement (actually, you don't need to do anything more that to simply define different policies for the different URIs). I'm not sure how useful such thing would be, though, and if it is, it's also doable with the single-URI-different-parameters approach, albeit requiring a bit more developers' involvement. As a last note, since there was also the discussion on wildcard policies, those could indeed mitigate the issues above. But, from security standpoint, I'd still prefer to have a clear way to distinguish between what _is_ a resource and what is "a mere" representation of one. As an analogy, it doesn't really matter that much if it is Eric Arthur Blair or George Orwell; what matters is that it's the person who wrote Nineteen Eighty-Four. ;) Cheers, Luchesar
- 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