Distinguishing HTTP status code 403 and 409 in practice (or 400)
Asked Answered
J

1

11

Even after reading many documents, books, spec I couldn't 100% be certain whether I should use http status code 403 or 409 in my case.

Some argue that 403 should be used only with an authorization issue, but seeing twitter's api using 403 for update limits violation, I think 403 actual use is broader than just authorization issues. Maybe it can be used to tell a request has violated a server-side constraint.

And, from the spec, 409 seems to be used when we can expect that client can resolve the issue.

I'd appreciate some variety of real world examples of when to use 403 and when to use 409, and for an opinion on which code to use in my case, which I will lay out in the abstract below (so as not to violate NDA).

After edit: The example is lengthy but, simply put, it is about what code to return when constraint validation fails. Do you always return 400 when constraint validation fails? Should I return 400 and not 403 or 409?


There is a client that tells service A which shelf contains a specific book. While recording to the DB which book is on which shelf, service A is able to tell the client that the client is trying to put the book in a wrong shelf. Service A can tell this by asking another service B that basically has some logic in deciding where a book should go to.

What http code should service A use in this case?

(The request conflicts with service B's decision -- 409? -- but the client is not able to resolve this problem because when service B makes a decision it is permanent. And book id and bookshelf id is both in the path parameter (ie, they are the only parameters in this endpoint) so the client can't really make any change to resolve the issue with the same request)

Additionally, the client is able to tell service A that a bookshelf should no longer be used (because it is full or for whatever reason). When the client tells service A that bookshelf C is not in use anymore, and then later the client tells service A that it wants to put another book on bookshelf C, service A should tell the client that it can't do that. What http code should service A use in this case? (The request will conflict the database status that says bookshelf C is not in use -- 409? But client is not able to resolve this problem because when a bookshelf is not in use, it is permanent in service A and it is never in use again -- not 409?)

Thank you in advance for your time and input!

Jannette answered 12/7, 2017 at 17:7 Comment(0)
C
1

Of the two codes mentioned, HTTP 403 is far more common and describes a valid (but unauthorized) request

HTTP 409 is not very common. It describes a conflict (like a deadlock or some other type of issue) that resulted in an error. I think Mozilla gives good advice when it describes this error most commonly occurring with with the PUT verb.

For a broader error condition, I would recommend using a 500 error code

Cerous answered 12/7, 2017 at 17:23 Comment(4)
Thank you for the input, do you mean 400 btw, when you said 500?Jannette
Nope -- I meant 500. Error code 500 indicates a generic application or server error. Error code 400 indicates a bad request -- it's the equivalent of indicating that one of the sent parameters was incorrect.Cerous
Hmm, at least in my case I wouldn't say it's server side error because I think it's client side that made erroneous request. I wanted to know if ppl use 403 for even not authorization (missing scope) issue. Or some real world examples of 403 or 409. But thanks for the effort!Jannette
In my practice 500 is used only for cases when the server couldn't process the request due to some unexpected condition. Best human-readable explanation for this would be "Oops, something went wrong". When the server knows exactly what's the reason for not processing the request, the response code should not be 500.Notable

© 2022 - 2024 — McMap. All rights reserved.