On Aug 27, 2009, at 9:40 AM, Felipe Gaúcho wrote:
>>> option #4: ??? waiting your best suggestion here :)
>
>> I would go with option 1. It means the resource /jug-a can have
>> representations about what it is.
>
> ok, but this will need to be inserted in all URLs :( .. I will think
> about ..
>
Careful use of parent/child URL relationships may make this easier to
support e.g. a sub-resource can obtain the URL of the super-resource
from which to build on.
Although i do not know much about the application you are designing it
seems that a JUG may be an important enough concept to have it's own
resource.
>> Are there permissions associated with JUGs? in that a user in JUG-A
>> cannot
>> access information or is restricted in updating information in JUG-B?
>
> I hope not :)
>
It actually should be fairly simple to support in Jersey using a
resource specific filter on the JUG resource. That filter can look at
the jug path parameter and determine if the user (from the
SecurtyContext) has access by checking what JUGs the user is a member
of. Kind of a bit like how the @RolesAllowed support is implemented.
> I am inventing this system right now.. and I believe there is no need
> for restrictions..
>
OK!
Paul.