2

I have a REST API in development were some resources are user related, and users need to authenticate to access those resources. It's tempting to take a shortcut and replace an identifier of:

/profile/[user_id]/

with

/profile/

considering that the user_id is known based on authentication data. In such case the /profile/ identifier means a different resource for each user. This does not seem very representational, unless we consider that the Authentication header is being a part of the identifier.
A more complex example when let's say there is an 'item' resource available for all users and every user can set their own 'label' property to an item. Again it's tempting to have just

/item/[item_id]/label/

instead of

/item/[item_id]/label/[user_id]

I have found one example where striping the user_id part has lead to potential problems (a case where an admin user was introduced, who should be able to access all users resources, but also filter them by user - A Web application as a REST API client: how to handle resource identifiers) but it didn't seem a very big issue. Are there any good reasons why authentication data should not be considered part of the resource identifier?

3

I've used /profiles/me before, it doesn't strike me as not representational. Some popular REST APIs have it as well. See this answer on SO.

If you're worried about ambiguity, you can always have a fully defined URI alongside the short one pointing to the same resource, and give that one to clients in sensitive contexts.

1

One good reason is cacheability. If you later decide to put a cache header on the resource and a different user logs in he will see wrong data.

Another is debugging. If you encounter problems with your token system and need to disable it during development it is nice that it can simply be disabled and the system still works.

It is not much more work to put a user id on the resource but it is a more correct solution.

  • The cache point seems interesting, but on the other side it mostly reminds me that (at least if we are considering browser cache) no resources which require authorization should use cache headers. Accidentally opening a cached /profile URL makes the issue obvious, but having a cached /profile/user_x when user_y starts using the browser is not much better from a security perspective. – dadasign Oct 25 '17 at 11:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.