Andy
Andy

Reputation: 8562

REST service call which starts a workflow?

We're building a web service and are trying to follow REST guidelines. The service allows users to create and modify their account and the profile that goes along with it (think email preferences, addresses, etc.).

For the most part I think we've gotten things to a pretty clean point, however there's a use case where I'm unsure if the fit is right.

Supposed we have a call /password where the user can PUT a request that contains both their current and desired password. This is fine, but we're trying to figure out an appropriate call to start the forgot password workflow, which kicks off some action on the server and the user gets instructions to their email on how to proceed.

Since the resources are supposed to be nouns and not verbs, adding a /forgotpassword somewhere in the URL doesn't make sense. One approach we've been considering is using the same PUT as for the change password but with a different Content-Type / Accept header to differentiate the desired outcome. I'm ok with this, but am wondering what some other options might be.

Upvotes: 1

Views: 101

Answers (2)

Jonathan W
Jonathan W

Reputation: 3799

If you're looking for a noun, how about a "password recovery" link relation which could serve as a collection under the user for recovery requests? A POST could kick off the workflow:

Request

POST /users/1/recovery-request
Content-Type: application/json

{
  email: "[email protected]",
  hint_question: 1,
  hint_answer: "MyMother'sMaidenName"
}

Response

204 No Content

This has the advantage of someone to be able to easily query the recovery collection to see how often you reset your password.

Upvotes: 2

Pedro Werneck
Pedro Werneck

Reputation: 41928

The most straightforward approach is assuming that a DELETE request to your /password is a request to reset the password. It should return a 202 Accepted response, and a GET to it should signal this until the password reset workflow is completed or timed out.

The user shouldn't be doing a PUT request containing both the current and desired password, unless the /password representation returns their current and previous password. PUT is a complete replacement. If that password is the one users use to authenticate to your service, you should expect an Authorization header. If not, then you shouldn't be using PUT and make it a POST.

Upvotes: 0

Related Questions