On Mon, Mar 24, 2008 at 2:15 AM, Adam Rosien <[EMAIL PROTECTED]> wrote: > You should set the HTTP status code to an appropriate value, in the > 400 or 500 range, via getResponse().setStatus(). See > http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10. For > your example, 401 Bad Request would be appropriate. > > You can also return a representation that may return additional > context information about the error, but there are no REST standards > for this; the status code itself should be enough for the client to > intelligently interpret. In Resource.put(), you'd return a > Representation object after you set the response status code.
One thing I'd personally recommend is doiing something like the SOAPFault fault structure, with -a string (faultcode) that you promise to leave alone over time for a specific error -some user visible error string you may improve over time -optional nested elements Way back when I was working on Apache Axis, I added in to their faults -a stack trace : good for finding where the problem lay in your code -the hostname: for identifying the machine at fault when you have a farm of them. these can both be turned on/off for security/privacy reasons for all the failings of SOAP, having a machine readable format for errors is useful. What you dont have to do in REST is -stick to 500 errors everywhere. For security issues, return some 4XX code with the fault -try and turn it into a predefined java, .NET or even C++ exception. For anyone generating an XML response, consider providing an xsl stylesheet to turn the XML into XHTML, so that the browser at the far end can turn it into something people can read *and paste into email messages*. It is the ability to paste stack traces into email that makes java stack traces and bugreps so wonderful. -steve
