Should ID be given in URL if already secured with JWT containing ID?

Question

Say I have the endpoints:

/users

and

/users/<id>

If I wanted to DELETE a user authenticated with a JWT token that contains the user object, should this DELETE handled go under /users or /users/<id>?

It makes sense to have under the /users/<id> endpoint as you're deleting that specific item.

But also makes sense to have it under /users as then you don't have redundant data and you don't have to enter the <id> every time you want to perform a function on your user when you already have the JWT authentication.

This idea falls to many-to-many objects too, say I wanted to access /users/<id>/games/<id>/move stripping '/users/<id>' makes it seem like there's not 'user' resource but it makes it less clunky and again less data redundancy.

Which is more 'accepted' or 'right'? Thanks :)

Answer 1

If the purpose of this end point is to perform an operation on the "current user" as defined by the user in the JWT token, then you absolutely don't want the User Id in the URL.

You don't want someone to maliciously change the URL to perform an action on a user other than their own, and implicitly using the JWT token for the user to operate on is a great way to ensure nobody is trying to screw with your system to do something they shouldn't be able to do.

Laiv brings up a good point in his comment on the question:

For refering the user authenticated /me. Looks to me less complicated. It's a very common alias and more intuitive than the cannonical uri (/users/id/). The action would be DELETE /me HTTP/1.1

Name your end point so clients of your service know they are performing an operation on their own user:

HTTP/1.1 DELETE /users/me

This tells clients "hey, I'm doing something to myself" and keeps them from accidentally doing something they shouldn't by munging the Id in the URL.

Answer 2

I think you are muddling the concept of the id of the user that is authenticated and the id of the user that you want to delete. I could be wrong but it's a little unclear when a user would delete him/herself and what that would mean. I would think the user being deleted and the user that is authenticated would typically be different.

For the second part of the question, I don't think it makes sense to make the games a subresource of the user. Games are a resource where each one has it's own ID. What user (or users) own the game or have access to it is an attribute of that game resource. You can use the authenticated user and their role to determine whether they have access to a given game. You would do something like this: /users/<id>/games to provide a list of URLs for the games that user is associated with.