CODEWITHSUNDEEP
resthttp-status-codes
jpmc26
jpmc26

Reputation: 29876

Proper status code for data that is well formed but invalid because of system state

I have a system where users are represented primarily with an integer ID. I have a resource; let's call it X. X is associated with 2 users: one created X and the other will approve X when the creator is done. X's approver is selected by the creator when it is submitted via POST (or can be edited in later), and the request identifies the approver by user ID. There's one additional restriction: approvers and creators are paired together. Approvers can only approve X if the creator is assigned to them.

So I have a few possible failure cases regarding the approver's user ID in the request:

  1. Malformed ID (non-integer)
  2. Approver ID is an integer, but no user with that ID exists.
  3. Approver ID is an existing user, but that user doesn't have the approver role.
  4. Approver ID is an existing approver, but the approver is not assigned to the creator.

400 is obviously the correct status code for case 1, but it doesn't seem like the right status code for 2-4. 400 designates a malformed request, but 2-4 are problems specifically with existing data, not with parsing the request. I considered 409, but that seems to be a problem with the resource itself. This is a problem with additional resources that are related to resource X. I also thought about 406, but that seems to be geared toward providing content in an unknown format (like XML when only JSON is accepted).

So what status code is appropriate to indicate that the client provided well formed but bad data?

Upvotes: 2

Views: 139

Answers (2)

Damien_The_Unbeliever
Damien_The_Unbeliever

Reputation: 239654

I agree with @Will for 1 & 2 - 404.

For 3 & 4, I would go with 409. Since in the general case (you said that the approver can be changed later) there's no real distinction (that I can see) between:

  • Approver ID is an existing user, but that user doesn't have the approver role.

and

  • Approver ID is an existing user, and 5 seconds ago they were the approver, but that is no longer the case

So it feels the same as an edit conflict.

Upvotes: 2

Boj
Boj

Reputation: 4053

Note that for clarity to clients you will always include an explanation of the error, so a slightly inexact code with an appropriate message will most certainly be helpful.

That being said, I would use 404 (Not Found) for 1 and 2. Integer or not, a resource with that ID does not exist.

Both 3 and 4 seem localized to our application, so I would use 400. 403 could be used for 3, but that might imply authentication problems.

Upvotes: 2

Related Questions