tags:

views:

63

answers:

1

How can I model roles views restfully?

Lets say I have a resource that can be viewed by a buyer or a seller (some content is shared between them on the resource, and some is unique to each one of them)

Should i make them a seperate resource: /resource/1/buyer, /resource/1/seller

or should i pass a format: /resource/1?viewer=seller

+2  A: 

I wouldn't put it anywhere. Instead, I'd have the same URL display the applicable parts of the resource based on the authenticated user.

User's roles are already decided upon when authenticating, makes no sense to require duplicating the data in the query. Imagine you have a complex user permission system. Would you then have the user duplicate their whole ACL in the URL? :/ This way the user doesn't even have to be aware of it's roles.

If the views are fundamentally different (e.g. don't share any fields at all or fields have different semantics), then I'd create two resources (/auction/1/buyer-info, /auction/1/seller-info). But this likely isn't the case here.

If there actually are multiple views of the same resource between which the user can choose, then I'd put the view in the query parameter (?view=simple), since it doesn't pertain to the resource itself, but actually is the "parameter of the query". But keep in mind that the query parameter here is "view", not "viewer" (like in your example), which IMO is an important difference.

By following this three approaches, you can cache the resource and then strip the relevant data from it based on a) the current user and b) the view query parameter.

Jaka Jančar