Mechanism to scope APIs

Viewed 83

I have different users who may be logged into a user interface and need to see different views of the same resources. So for example, a family shares a shopping application. When the parent logs in they can see everything in the cart. When the child logs in they can't see certain products in the cart, and for the products they can see they can't see certain attributes (e.g. price).

So from a resource perspective if we want the parent and child to have two different views of the cart, one way to do this would be:

/parent/shoppingcart

and

/child/shoppingcart

Another way would be:

/parent.shoppingcart

and

/child.shoppingcart

What is best practice from an API / REST perspective?

Note: I can't do,

/shoppingcartsummary

and /shoppingcart

because there are even more views than the parent's and the child's.

2 Answers

Best practice would probably be /shoppingcart/parent and /shoppingcart/child. Pretty sure if you can do "/parent/shoppingcart", you can do "/shoppingcart/parent".

Shoppingcart would be the common/generic portion of the view (and up on the controller, the common functionality such as retrieving the list of products in preparation for displaying them in some manner, or not). Based on authorization level, the 'parent' or 'child' sub-view extends shoppingcart and clarifies the exact representation.

Of course only the parent would have access to /shoppingcart/parent. The parent would of course also have a link "View as Child" to view /shoppingcart/child.

Of particular importance, do Not rely on the Client/Browser to directly specify what it is, for example to send Content-Type to specify a parent or child.

You have one resource, a /shopping-cart. You have multiple representations of that resource - one for parents, one for children, etc. You can keep one endpoint (for the resource), and use the Accept header with custom content types, such as vnd.mycompany.child, to specify the desired representation of that resource.

Related