Is it a good practise to tread HTTP credentials as a part of a resource identifier?

Question

I'm designing a service which will require HTTP basic or digest authentication. I'm trying to weight pros and cons of using HTTP credentials as a part of resource identifiers. Say each authenticated user has a list of contacts. Should the contacts be available as:

https://myservice.com/contacts

or rather:

https://myservice.com/users/112358/contacts

?

In case of this service, users need to be isolated. There never will be any need for a one user to access contacts or any other information associated with another user. For this reason, the first approach seems cleaner, as it only exposes necessary information in the URL. On the other hand, for different HTTP credentials, https://myserevice.com/contacts will be a different resource, which I'm not sure is a good design.

Answer 1

I'd go with https://myservice.com/users/112358/contacts.

If only because there may be resources "under" users that may at some point be viewable by other users. For example user X being able to see documents of user 112358.

Consistency in URI's is an advantage. Even if, using HATEOAS, consistency in URI's is not so much a concern on the outside, it will be helpful growing and maintaining the API's implementation.

Answer 2

For the same reason you cite at the end of the question, that /contacts would represent different resources depending on credentials supplied, I recommend that you go with the second, longer option. Are users expected to remember and type these URLs into their browser? If not, length and 'prettiness' should not be a significant factor.

Don't forget, you can always return a temporary redirect from /contacts to that user's own contacts.