Assuming I have a RESTful service and it always responds in this format:
{
"error": {
"code": ...,
"message": ...
}
}
or
{
"data": ...
}
and there is a method like POST /users/me/change-password
.
What would be the correct and RESTful behavior:
Business logic / validation errors are data
- Password has been changed (200, empty error and data)
- User is not authenticated (401, error = 1, empty data}
- Password policy: password has already been used (200, empty error, data = 1)
- Password policy: password doesn't match requirements (200, empty error, data = 2)
- SMS-OTP confirmation required (200, empty error, data = 3)
- Incorrect SMS-OTP (200, empty error, data = 4)
- The user has disabled password changing (200, empty error, data = 5)
It seems correct since errors like "SMS-OTP confirmation required" are not even client errors. A client did nothing wrong, and expects an "OK" response.
Business logic / validation results are errors
- Password has been changed (200, empty error and data)
- User is not authenticated (401, error = 1, empty data}
- Password policy: password has already been used (400, error = 2, empty data)
- Password policy: password doesn't match requirements (400, error = 3, empty data)
- SMS-OTP confirmation required (400, error = 4, empty data)
- Incorrect SMS-OTP (400, error = 5, empty data)
- The user has disabled password changing (400, error = 6, empty data)
It seems correct since 200 OK status suggests that password has been changed succesfully, whatever written in response. However, some clients like C#
WebClient
do not even return non-OK responses, they just throw exceptions.
The same questions arise in terms of all authentication requests. For example, is "username is already occupied" for "sign-in" an error or data.