[OTDev] encoding accept header MIME types in URI

Luchesar V. ILIEV luchesar.iliev at gmail.com
Thu Jan 13 08:07:36 CET 2011


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



More information about the Development mailing list