I have studied various resources for URI design best practices. Almost every author or blogger says RESTFul API URI have to look like this for example.
/* List all users in account 2 where user id is 1 */
`/users/1/accounts/2/users` [GET]
Above api caller have to pass above two ids in every request.
But my scenario is quite different.
There is a Resource Manager(RM) before my API server so every request have to pass through RM for authentication with valid token to access above example API. Note: [token send via header]
Once request is authorized in return RM provide user info i.e.(user_id, account_id etc.) to my API server via interceptor.
Question is my API server is already aware of user_id and his account_id then still there is need to get these information in API URI.
I have tried following design:
1. /users/accounts/users
2. /accounts/users
3. /users
What is best suitable design for this scenario? I spent two weeks but couldn't decide because these are enterprise APIs design; once designed than will never changed.
You should include ids in the URI for the very reason you give at the end - your API will be very difficult, maybe impossible, to change once it's being used. On the other hand, your implementation will change over time. Your authentication / authorization mechanism could change. Your enterprise may wish to move to an model which doesn't pass around ids in this fashion, and they certainly won't want to find that they have to re-design every single API which depends on the old behaviour.
At the end of the day, including enough information in the URI for the URI to identify the resource it relates to is a key part of ReST. The URI should be all that you need to identify the resource, you don't depend on out-of-band information or implementation details to further identify the resource you're addressing.