Re: Should a response body for errors be standardized?

[Sam Ruby <rubys@xxxxxxxxxxxxxxxx>]

Joe Gregorio wrote:
> How should errors be handled? That is, an HTTP Status code needs to be 
> returned when an operation fails. Should there be a response body on 
> errors, and if so, what should it look like? I see three possibities, if 
> you have other ideas please add to this list:
>
>   1. Don't specify a format for the response body, let the server decide 
> the format of what to return.
>   2. Specify a mimi-type of the text/plain, so the error string can be 
> presented to the user.
>   3. Return and XML file with formatted error info:
>
>   <error>        <title>Can't create Entry</title>        
> <description>Your bloggging service subscription has expired.  
>            Visit reup.example.com to renew your subscription 
> today!</description>    </error>

Why reinvent?

http://www.w3.org/TR/SOAP/#_Toc478383507

I am often (rightfully) accused of being too obtuse.  So let me be 
explicit in what I am suggesting here.  Design a pure REST API.  Where 
there seems to be places where "some invention is required", see if one 
can reuse precisely those elements - and only those elements - from 
SOAP.  What you will end up with is a fully REST compliant interface 
which will enjoy wide tooling support.

>     Thanks,
>     -joe