7

I'm developing a simple RESTful API, and utterly in love with how minimalistic it is. But I'm uncertain as to the correct HTTP response codes for various situations:

  1. Incorrectly formed query

  2. Correctly formed query refers to a resource which does not exist

  3. Resource successfully deleted

  4. Resource successfully edited

I'm currently thinking that 1 would be 403 Forbidden; 2 would be 410 Gone; 3 and 4 would be 202 Accepted. Do they sound right?

Marcus Downing
  • 10,054
  • 10
  • 63
  • 85

5 Answers5

15

For #1, 403 suggests your application understood the request, but wont fulfil it (i.e. current user doesn't have permission to do that for some reason). I think 400 bad request might make more sense in this case.

For #2 - I would think 404 would make more sense i.e. resource is not found, unless the resource did exist at some point, and has then been deleted, in which case 410 would be fair - but not many clients know what to do with 410.

For #3 & #4 - 200 if you processed the deletion successfully, 202 if the deletion is queued up and will be handled at a later date "out of band".

RFC 2616 provides great explanations of what each response code means in fairly understandable terms.

Bittercoder
  • 11,753
  • 10
  • 58
  • 76
  • "but not many clients know what to do with 410" - luckily I get to write the client too. – Marcus Downing May 11 '09 at 10:58
  • If I use 404, how is that different from "404 the server didn't understand a word of what you just said"? – Marcus Downing May 11 '09 at 11:00
  • 1
    404 is *supposed* to be used for Resource Not Found. If it's just an unintelligible request, 400 Bad Request seems more appropriate. – Hank Gay May 11 '09 at 12:06
  • Yeah, but 404 is what Apache uses for "no page here", Tomcat for "no servlet here", and so on - errors outside of my control. – Marcus Downing May 11 '09 at 15:11
  • 7
    404 really refers to the url, rather then the contents of the request - so if you're url does not point to a valid resource, 404 is the more meaningful response. If say your client POST'd to http://myapp/orders/, which is a valid url/resource, but the contents of the POST request was invalid, then a 400 error makes more sense. Additionally there are other responses for certain scenarios, 405 method not allowed, 403 forbidden, 406 not acceptable, 409 conflict & 415 unsupported media type, which generally crop up if you don't control the client. – Bittercoder May 11 '09 at 20:01
4
  1. 400
  2. 404
  3. 200
  4. 200
  5. 201 - resource successfully created
1800 INFORMATION
  • 131,367
  • 29
  • 160
  • 239
2

1). 400 - standard bad request, 403 means the request is formatted correctly but you are not allowed to access it

2). 404 - a 410 implies that the resource did exist but has been deliberately moved

3). and 4). 200 if the action has happened successfully by the time you send the response, 202 if the action is pending. In practice 202 is likely for delete actions (where they might be subject to review) but you may or may not want to immediately return a 200 anyway so it appears actually deleted to the user. That's a design question imho.

annakata
  • 74,572
  • 17
  • 113
  • 180
1

Get the Richardson & Ruby book - it has a useful appendix on your question and is required reading either way

Ruben Bartelink
  • 59,778
  • 26
  • 187
  • 249
-1

why not use the standard http response codes . You would get all the optimizations ( for ex, 303, 304 )/ infrastructure put in place for http for free .

Surya
  • 4,922
  • 8
  • 41
  • 54
  • 1
    I am, of course. The question is which ones are appropriate for different cases, since the codes are described in terms of accessing pages. – Marcus Downing May 11 '09 at 17:30
  • Yeah..sorry . I guess I misread the question . I would use 400 bad request for 1, with reason code in the response body. – Surya May 12 '09 at 04:33