Home/ Questions/Q 8523081
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-11T07:18:27+00:00

I was at a developer conference where the speaker argued that the following set

  • 0

I was at a developer conference where the speaker argued that the following set of URLs are not RESTful:

/users/username/changepassword
/users/username/resetpassword

The main reason given was that the same URLs might be used in different context and that this didn’t facilitate HATEOAS in a meaningful way.
He then continued to argue that a more viable approach is to use the following URLs:

/account/changepassword
/administration/server/users/username/resetpassword

According to the speaker this latter approach allowed for each use-case to have a specifically tailored (html-)form for each URL, which could then be posted to the same URL. No more problems with the same URL used in different contexts.

I would spontaneously say that neither of these URL sets are RESTful, simply due to the fact that they are both centered around actions (verbs) which in my eyes do not really qualify as resources except for in exceptional cases (like search). I feel like this setup is very RPC-like.

I would have suggested something more noun-like and granular like

 //Change password
 PUT /users/username/account/password
 //Register reset
 POST /users/username/account/password/resets
 //Verify reset
 PUT /users/username/account/password/resets/0/verification_code

What is your opinion? Is the speakers approach RESTful or not, or is there simply not enough information here?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I agree, the whole idea of a RESTful interface (as I understand it) is to allow access to “resources”. So neither of those URL schemes seem very nice to me.

    Having said that REST isn’t set in stone, it is more of a guide than a set of rules. Some things don’t sit that well with it, so you have to get as close as you can just using the HTTP verbs.

    A password reset isn’t a resource, however a password is. So, I would say something along these lines for a password reset operation …

    GET /users/antonyscott/password
PUT /users/antonyscott/password

    With the 2nd call requiring authentication of some sort derived from the first call and passing in the new password. Actually that’s more of a straight password change than a reset. If you’re after a reset (ie – following a link in an email to confirm the reset) then what you had seems okay.

    Obviously designing an API is an iterative process, so I would say have a go and see how it works, then refine it.

    • 0