How to model a password reset endpoint and its parameters?

1

A few questions:

  • How does everybody here handle spec-compliant password reset resources, .e.g. /passwords and /users/1/passwords, or even non-standard resource endpoints in general?
  • How do you model the parameters – non-standard?

These seem kind of weird, but maybe okay:

POST /passwords
{
  "data": {
    "type": "passwords",
    "attributes": {
      "email": ...,
    }
  }
}

POST /users/1/passwords
{
  "data": {
    "type": "passwords",
    "attributes": {
      "passwordResetToken": ...,
      "password": ...
    }
  }
}

Or what about using meta instead?

POST /passwords
{
  "meta": {
    "email": ...,
  }
}

POST /users/1/passwords
{
  "meta": {
    "passwordResetToken": ...,
    "password": ...
  }
}

I like the last one, but not entirely sure if that is compliant.

2

Meta is a compliant way of doing anything at all. It’s a bit of a copout though, and absolutely relies on documentation instead of discoverability.

Personally I’d do it as a write-only relationship from the user. Maybe the read version tells things like when it was last changed. Unfortunately this also relies on documentation - if you can’t read a field how do you know you can write it - but it feels a bit better to me.

3

So far, I’ve used meta as a last resort in situations where:

  • the endpoint, in some conditions, returns additional attributes, and these attributes can be different
  • and it does not seem natural to split them up as a separate resource

Since password is not a resource, and user has a password, how about using a user type?

POST /passwords or POST /users/1/passwords

{
  "data": {
    "type": "users",
    "attributes": {
      "password": ...,
      "password_reset_token": ...
    }
  }
}