2

I'm writing a Plain Old XML HTTP request/response service and am looking for advice as to how to respond to the caller.

Given that the response is XML, would you advise:

  1. Return HTTP Status 200 all the time, and embed the response success/failure inside the XML, using a kind of "return code" approach? e.g. <myResponse><returnCode></returnCode><myPayload/></myResponse>

  2. Use the HTTP Status Codes to indicate success or failure.

This may be similar to this question.

Community
  • 1
  • 1
  • Being a big fan of RESTful services, I'd advocate that you always use the applicable response code and add the details in the response content. Is there a particular reason not to use the codes? – David Dec 15 '11 at 20:04
  • No, there is no specific reason I can think of other than general ignorance and my own tradition/ experience of consuming other similar services –  Dec 15 '11 at 20:06
  • In that case I'd definitely recommend using the applicable response codes until such a reason becomes an issue (such as a connecting client that handles codes incorrectly). It's a pet peeve of mine when I connect to a service that breaks HTTP standards. I once had to integrate with a service that would indicate a "404" by sending a redirect and then returning a 200 where the page content just _said_ 404 in it. So basically the service said, "That resource has moved here... This resource is the correct one. But it's still not found." Made no sense to me. – David Dec 15 '11 at 20:09

2 Answers2

1

Google and Amazon services use returning 200 only if your request was valid AND the response is valid.

For example using Google Contact API

  • If you request a Contact that exists: 200 + XML/Json of Contact
  • If you request a Contact that does not exists: 404 + Xml/Json with Details
  • If your request is formatted improperly: 400 + Xml/Json with Details
  • If you have not sent the authorization token: 401 + Xml/Json with Details
  • If you attempt to Insert a contact using Get or Put: 405
  • If you Attempt to Insert a Contact using Post: 200 (assuming the request contant was valid)
  • If you Attempt to Update a Contact using Get or Post: 405
  • If you attempt to Update a Contact using Put: 200 (assuming the request contant was valid)
  • If you Attempt to Delete a Contact using Get, Put, Post: 405
  • If you attempt to Delete a contact using Delete: 200 (assuming the request contant was valid)

I would highly recommend you do NOT always return a 200. The HTTP Status codes are designed around a response code result that represents the request. As shown above, if you request is not correct, then using HTTP Status codes is a valid solution.

I would recommend using a 5XX if there is a problem on your end. I really wish Google would do this. (At one point their Experimental OAuth 2.0 endpoint was not working, and instead of throwing a 503 - Service Unavailable, I was getting a 400 - Bad Request, which made me thing I was doing something wrong....)

For descriptions of the HTTP Status Codes check out RFC2616.

Erik Philips
  • 53,428
  • 11
  • 128
  • 150
  • If I'm not suggesting that the service is RESTful, or REST-compliant, what would the HTTP response codes give me over my own application-level response structure? –  Dec 15 '11 at 20:47
  • You would be using it as it was intended to be used. I personally would rather see an HTTP response. My preference is based on using other large corporations who also do the same thing. – Erik Philips Dec 16 '11 at 18:19
  • Upvoted because many people who write webservices should keep it in mind for future reference... – neemzy Jan 07 '13 at 14:49
0

I would think that you'd want to go with option 1 because your request could be successful but something fails on the backend in your api. I wouldn't return a response code of 200 all the time though, you could run into a case where say the url for the web service doesn't exist, in that case you'd want to return the appropriate response code.

spullen
  • 3,227
  • 18
  • 25
  • Using your example, wouldn't a non-existent URL 404 response be handled by the web server? –  Dec 15 '11 at 20:53