I'm trying to create an api which has a login that issues a JSON web token and then offers a handful of resources to authenticated requesters.

User is a type of resource, and this is where I get confused about routes. In some cases, authenticated users GET information about other users, like this:

/api/user/<any user id>/favoriteBooks

But in most cases, authenticated users may GET information only about themselves. How should those requests be formed?

A: /api/user/1234/homeAddress. 1234 must be the caller's user id, and this returns an error if the route user id disagrees with the token user id.

B: /api/user/1234/homeAddress. 1234 must be the caller's user id, but this version ignores that and just returns the info for the user indicated by the token.

C: /api/user/homeAddress. same as B, except this one dispenses with the redundant route user id which B ignores anyway.

A seems the most conventional, but contains an unnecessary error path, B seems a little misleading, and requires redundant information that is ignored, and C is most appealing to my intuition, but I've never see routes like this. If a REST route must fully describe the request, then this one would be odd, too.

Is there a strong rule or norm that I can use to guide me here?


1 Answer 1


Option C is the correct approach.

Exposing a UserID in an API endpoint that already knows what the UserID is just leaks an implementation detail for no good reason and adds superfluous complexity to the API call.

To make the call even clearer, you can say:


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.