What do you return when already returning an HTTP status code that isn't 200?

[M. Herold]

From the implementation of ServiceStack having ResponseStatus for response DTOs, I haven't been returning any HTTP status codes on my own, well that is until I realized I wasn't really following the standard HTTP protocol by doing so. With that, what is it I should be doing? I basically have just a couple of situations:

1) 200: return the DTO as normal, no response status is filled

2) 404, 401 and 500: return an empty (nearly) DTO except it contains a ResponseStatus with my custom error code and error message.

I imagine I should be supplying some custom headers with my responses too, but I'm again not certain what the standard is, and I'm having a hard time finding a consensus online. Part of me thinks I shouldn't be returning a DTO when there's an error, but that would cause troubles for applications expecting JSON and just getting an error that it needs to check in the header. I mean, who is really going to use the HTTP status code or its associated header anyway?

Should be RESTful for the sake of being RESTful?

[Demis Bellot]

ServiceStack helps you here where by default it turns C# Exceptions into optimal HTTP Status code, e.g by default C# Exceptions:

• Inheriting from ArgumentException are returned as a HTTP StatusCode of 400 BadRequest 
• NotImplementedException is returned as a 405 MethodNotAllowed 
• Other normal C# Exceptions are returned as 500 InternalServerError

You can read more about ServiceStacks built-in Validation and error handling, as well as how to return your own Custom HTTP Error messages at:

https://github.com/ServiceStack/ServiceStack/wiki/Validation

Note: Managed exceptions in ServiceStack will return errors in the appropriate format, e.g. calling JSON will return a structured JSON DTO with the Response Status pre-populated.

Often returning an appropriate HTTP Error where appropriate helps users of your API make use of your API correctly, e.g. 400+ errors says there is something wrong with the client request (which the client needs to rectify), whereas 500+ errors suggest there's something wrong with your service which would indicate to your client to notify you that your API is returning an un-expected error.

Cheers,

--
- Demis

http://twitter.com/demisbellot

http://www.servicestack.net/mythz_blog

[Michael Herold]

Hrm, thanks a lot Demis, that makes sense!

A quick follow-up: what do you return on successful POST, PUT and DELETE requests? 

[Demis Bellot]

It automatically returns back a 200 OK for you (i.e. the most appropriate success code :).

Cheers,

[Michael Herold]

I mean, in terms of the DTO: should I return anything? Just mirror the request? 

[Demis Bellot]

I prefer returning an empty DTO myself, but null works as well (i.e. no response).

Cheers,

[Michael Herold]

Ah, I dig that. Thanks again! 

[Darren Sherwood]

For other's ref if they want to be 100% correct and they are not returning a response body, you do allow them to override response code as such:

base.Response.StatusCode = (int)HttpStatusCode.NoContent;