Perhaps what I'm thinking about is a bit of a corner case, but I'm thinking
in of a situation when you want to potentially control the type of
representation at a particular URI. For example, supposing the Facebook API
was a true RESTful application and they offered a free and paid plans to the
service. In the free scenario, if I call the following URI:
http://api.facebook.com/people/12345
I can see basic details about that user like their name and status, but I do
not see their friends and other details. If i'm a paid service member, the
representation that is returned would have more detailed information about
the person and you'd be able to see friends and other details.
From a coding perspective, I was thinking it could be something like:
@UriTemplate("/people/{id}")
@ProduceMime("application/xml")
public class PersonFinder {
@HttpMethod("GET")
@RolesAllowed({"basic"})
public Person getPersonByIdBasic(@UriParam("id") String id) {...
@HttpMethod("GET")
@RolesAllowed({"paidSubscriber"})
public Person getPersonByIdFull(@UriParam("id") String id) {...
If the user is in the "paidSubscriber" role, the getPersonByIdFull() is
executed. Again, maybe this is a corner case, but it's something that has
come up in a project I have been working on.
Ryan-
On 8/24/07, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
>
> On Aug 24, 2007, at 11:45 AM, Ryan McDonough wrote:
> >
> > Sorry I'm late to the party but I've been trying to catch up on
> > what has
> > been going on with the development of this specification. One item I'm
> > curious about is security in regards to this JSR? Is this an area
> > that has
> > been deemed out of scope for for the JSR, or is something that has
> > not come
> > up in discussions yet?
> >
> We haven't discussed security much beyond noting that its primarily
> something that would typically happen before a request reaches a JSR
> 311 artifact. In an earlier note[1] outlining feedback Paul and I
> received from an internal review I included the following:
>
> > - Consider supporting the standard security annotations defined by
> > JSR 250 and examine JSRs 196 and 115. JSR 196 offers support for
> > pluggable authentication and JSR 115 for authorization. JSR 115 may
> > need a revision to accommodate the more flexible URI patterns
> > supported by @UriTemplate.
>
> So I wouldn't say that security is out-of-scope for this JSR but
> equally I don't think we should be re-inventing any wheels either.
>
> Marc.
>
> [1] https://jsr311.dev.java.net/servlets/ReadMsg?list=dev&msgNo=549
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
>
--
Ryan J. McDonough
http://www.damnhandy.com