On 13 January 2011 09:07, Luchesar V. ILIEV <luchesar.iliev at gmail.com>wrote:

> 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.
>

Actually, it's not that bad from security point of view, because the REST
framework will handle the extensions itself and adding an extension is
merely a configuration issue.

But you are at the mercy of the framework, and here I understand these
differ. The Ruby framework as explained in Christoph's email works via URI
rewriting, while Restlet works via "tunneling", i.e. rerouting the request
to the proper code, rather than rewriting the URI.  Thus in Restlet we end
in the proper code to handle the request, but with the original URI . And if
we want to check if the URI is authorized by the OpenSSO server, we have to
do the extension removing ourselves :(


>
> 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.
>

Sometimes it make sense, as text/uri-list returns much less information than
application/rdf+xml . But I guess it complicates things further.

Best regards,
Nina


>
> 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
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>