Say I have the endpoints:




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 :)

  • 3
    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. – Laiv Dec 8 '17 at 16:52

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.

  • This answer is absolutely wrong. You want to identify the resource to be deleted. that identifier is the URI of the resource. Successfully DELETE-ing the /user/me resource means no-one else will be able to GET the /user/me resource. You should use ACLs to determine which /user/:id objects are able to be deleted by the authenticated user (which for an ordinary user, is probably just themselves). – Nicholas Shanks Dec 18 '17 at 15:11

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.

  • My point is to DELETE a user you must already be authenticated as being that user, in my case you will have a JWT. In this JWT there is encoded the PK in the database to the user object you wish to delete. So if I send an authorisation header with JWT<token> I don't need to repeat it in the URL again? I hope that cleared my intentions. – Skidushe Dec 8 '17 at 17:18
  • So your design is that a user can delete his/her own resource and no one else can? – JimmyJames Dec 8 '17 at 17:32
  • Yes. Only a user can delete his/her own profile. – Skidushe Dec 8 '17 at 17:33
  • So an administrator can't do that? What happens when a user delete's his/her profile? Are you going to invalidate their authentication/authorization? – JimmyJames Dec 8 '17 at 17:35
  • I don't have a concept of an administrator account as I don't see a purpose for one in my circumstances and the JWT will be inherently invalid once the user is deleted as the the JWT checks against the user object in all circumstances. (it's now deleted) – Skidushe Dec 8 '17 at 17:38

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.