CODEWITHSUNDEEP
rest
Etki
Etki

Reputation: 2144

REST operations and status codes

I'm invoking some kind of operation via a REST call, e.g. raw password vs. stored hash match:

POST /v1/user/:id/password/verification HTTP/1.1

{"password": "correct staple battery horse"}

The question is, should I use status codes to explicitly specify operation result? On the one hand, REST means dealing with resources, so I create a resource "password verification operation" which may have failed. On the other hand, this resource has been created anyway - it just the operation that has failed, and there is absolutely no correct status code for marking operation failure - 404 would mean there has been no operation at all (that's a lie) or that password doesn't exist (and "provided password doesn't match stored hash" with "stored hash doesn't exist" are completely different outcomes), 403 isn't correct too because access has actually been granted for that operation.

So, should I use status codes for binary output (true/false) operations, or should I simply stick with passing the result in returning payload?

Upvotes: 0

Views: 46

Answers (1)

Avi
Avi

Reputation: 21760

If you go by the book - you should find a suitable status code for your operation. In your case I would assume it would be something in the 50* area which indicates an error but not necessarily that the resource hasn't been created.

That's if you go by the book. De-facto, I have used many REST APIs that don't go by the book and just return their own statuses. For example, it's not uncommon to get back a 200 OK status code because the HTTP request-response roundtrip worked correctly but still receive an applicative error-code in the payload. Not sure that's the path I would choose, but, as I said, it's not that uncommon. Even facebook API is working like that (or worked like that like 4-5 years ago when I last used it).

Upvotes: 1

Related Questions