On Mar 28, 2010, at 7:20 AM, Ersin Er wrote:
>
> In my application there are two types of users, let's simply call them USER and ADMIN. Some service methods (resources) can be accessed by both roles but they are expected to behave differently according to the role of the actual user. For example, ADMIN users can see all items in a list, while USER users can see only items that belong to them. If I annotate such a method with @RolesAllowed({ "ADMIN", "USER" }) then I need to do further checks in the method (via isUserInRole()) to distinguish between the roles. As an alternative I can introduce a new container like /admin and serve all administrative methods over this one to only ADMIN users. In this case the same resources are being accessed via more than one entry point which I do not feel very comfortable with, with respect to RESTful design principles.
>
> How would you design your application in such a case? (Well, it's not that much an interesting case. Just wanna get your ideas on the subject.)
>
This is one of those questions that doesn't have a right or wrong answer, it all depends on your requirements. If your application has the need to identify the items belonging to a particular user then I'd make the user id (or some encoded form of it) part of the URI. That would argue for a URI design along the lines of /users/xyz/items rather than just /items where the authenticated user determines the resources context. With this style of URI design I don't see any great need to distinguish between admin and normal users but, if it makes the implementation easier, then I can't see any harm in doing that either.
Marc.