REST HTTP status codes

views:

224

answers:

+3 Q:

REST HTTP status codes

I'm building an application with a REST-based API and have come to the point where i'm specifying status codes for each requests.

What status code should i send for requests failing validation or where a request is trying to add a duplicate in my database?

I've looked through http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html but none of them seems right.

Is there a common practice when sending status codes?

+1 A:

For input validation failure: 400 Bad Request + your optional description. This is suggested in the book "RESTful Web Services". For double sumbit: 409 Conflict

deamon 2010-07-20 13:05:04

"The request could not be understood by the server due to malformed syntax"? I'd say that's not quite the case here - the request is understood, but the server can't/won't fulfill it.

Piskvor 2010-07-20 13:18:29

Yes, the request body is part of the syntax.

deamon 2010-07-20 13:22:11

Yeah, 400 Bad Request seems to be the closest option.

alexn 2010-07-20 13:24:33

@deamon: indeed it is; what I'm saying is this: "Bad Request" would is something like "I don't know what you want me to do", not "I know what you want from me, but that is not possible for some reason"

Piskvor 2010-07-20 13:26:31

I will go with 400 Bad Request and 409 Conflict until i find something that fits better.

alexn 2010-07-20 13:43:54

Bad request is definitely the most common response to this kind of issue. The only other alternative is 422 Unprocessable Entity. It actually comes from WebDav but it is perfectly valid to reuse any status code that has been registered with IANA.

Darrel Miller 2010-07-20 19:38:11

+1 A:

403: Forbidden would be the most appropriate response if they fail authentication. For a request trying to add a duplicate, 400: Bad Request would probably make the most sense.

no 2010-07-20 13:10:13

That would be wrong. Forbidden means "not authorized".

deamon 2010-07-20 13:15:39

And failing authentication means "not authorized." So failing auth gives a response of "forbidden." What's wrong with that?

no 2010-07-20 13:16:59

You suggested to use "forbidden" for input validation failures.

deamon 2010-07-20 13:19:04

@deamon, @no: That is a common misconception - according to the spec linked in the question, "403 Forbidden" means "The server understood the request, but is refusing to fulfill it." - where failed authorization can be one of the reasons, but it's not the only possibility.

Piskvor 2010-07-20 13:20:45

deamon 2010-07-20 13:33:08

Somehow I read "validation" as "authentication" when reading the OP. If it does mean form field validation, 403 is probably not the most appropriate response. However if it means user validation (aka authentication) 403 is perfectly okay... It's the same code apache will throw when basic HTTP authentication fails.

no 2010-07-20 13:45:08

@deamon: It is "forbidden" - as in "request received, will not act upon it"; the fact that it's used as "...because you don't have authorization" in 99% of the cases, doesn't mean it's the only allowed use. Do read the HTTP spec, some parts may surprise you.

Piskvor 2010-07-20 13:45:54

@no: Are you saying "this is the One True Way to implement RFC2616, because that's what Apache does"? (You do have a point that most people expect '403 can *only* mean "authorization failed"')

Piskvor 2010-07-20 13:50:04

Piskvor, of course not, I'm just saying there's definitely precedent to use it like that... whether it's appropriate for form validation errors is open to interpretation, but I'd say it's "more appropriate" for failed authentication than anything. It would also make sense for denying a directory listing, say if the user tries to navigate to mysite/somedir/css.

no 2010-07-20 14:00:48

+1 A:

Failed validation: 403 Forbidden ("The server understood the request, but is refusing to fulfill it"). Contrary to popular opinion, RFC2616 doesn't say "403 is only intended for failed autentication", but "403: I know what you want, but I won't do that". That condition may or may not be due to authentication.
Trying to add a duplicate: 409 Conflict ("The request could not be completed due to a conflict with the current state of the resource.")

You should definitely give a more detailed explanation in the response headers and/or body (e.g. with a custom header - X-Status-Reason: Validation failed).

Piskvor 2010-07-20 13:24:04

Care to provide a reason why this is *not* a good answer?

Piskvor 2010-07-20 13:41:49

I think this is a good answer with valid points. +1 for offsetting the downvote.

alexn 2010-07-20 13:43:06

"403 Forbidden" has another semantic. See http://en.wikipedia.org/wiki/HTTP_403

deamon 2010-07-20 14:09:57

@deamon: That is *not* the specification, that's Wikipedia, i.e. someone's opinion on "what HTTP status codes mean"; note that the page essentialy says "this is what Apache means with 403, this is what IIS means with 403", and nowhere does it reference the official RFC. You seem to be repeating "403 means whatever Apache says". NOT. The actual RFC (which is the relevant document, not Apache's implementation, not IIS' implementation, not anyone else's implementation) is here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Piskvor 2010-07-20 14:28:59

I know this specification. The emphasis is on "forbidden" what means "access denied in any case".

deamon 2010-07-20 14:37:36

"10.4.4 403 ForbiddenThe server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead."I see no emphasis there ("SHOULD/SHOULD NOT" are RFC 2119 keywords, not emphasis); that's your idea what "forbidden" means, not RFC's.

Piskvor 2010-07-20 14:53:16

I recommend status code 422, "Unprocessable Entity".

Julian Reschke 2010-07-20 14:56:26

this is not a http status code

deamon 2010-07-20 15:10:38

The WebDAV extensions! Good point, haven't thought of that.

Piskvor 2010-07-20 15:10:39

Of course it is an HTTP status code, see http://www.iana.org/assignments/http-status-codes. There are more status codes than those defined in RFC 2616.

Julian Reschke 2010-07-20 15:16:09

@deamon: Speaking of non-codes, the Wikipedia page you linked to (somewhere in this question), notes several sub-statuses (which are not even *syntactically valid* HTTP status codes - "The Status-Code element is a 3-digit integer result code") invented by the IIS server team ("403.4 - SSL required"). Trying to eat your cake and have it, too?

Piskvor 2010-07-20 15:24:00

WebDAV is a HTTP **extension**. "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)" So, status code 422 is not a http status code, but a status code of an extions of http.

deamon 2010-07-20 15:28:05

deamon, that doesn't make sense. HTTP defines how to define new codes, and that's what WebDAV is doing. There's a status code registry for a reason.

Julian Reschke 2010-07-20 15:32:17

What, no `418 I'm A Teapot` in the registry? I'm shocked, shocked!

Piskvor 2010-07-20 15:52:08

Piskvor, that's actually questionable :-). It probably wouldn't happen under the registration procedure defined in the current draft.

Julian Reschke 2010-07-20 15:53:21

Piskvor, Oh, it's NOT in. Good. :-)

Julian Reschke 2010-07-24 07:45:13

ansaurus

tags:

views:

answers:

REST HTTP status codes

related questions