[WSG] REST HTTP error codes and responses for form/parameter validation
Any RESTafarians around? I'm implementing a REST API and am wondering if there's a standard / standard practice / strong opinion on what HTTP status codes map to form validation errors when processing HTTP REST requests. Say for example I have the following HTTP request: POST /tags/rails/messages/ PARAMS: message[name]=hello&message[body]=this+is+my+first+message HTTP-ACCEPT: text/html; ... This is just like doing a POST submission from a "New Post" HTML page. If there was a form validation error, e.g. a "blurb" parameter is required, the web browser would normally just return a 200 OK and the HTML page would show the error message. 200 OK The required field "blurb" was missing In the REST XML-based API I'd like to indicate the form validation error via the relevant HTTP status code and HTTP response body. POST /tags/rails/messages/ PARAMS: message[name]=hello&message[body]=this+is+my+first+message HTTP-ACCEPT: application/xml; ... 400 Bad Request The parameter post[blurb] was not specified For creating a new resouce I'm thinking 403 Forbidden, or maybe 400 Bad Request? For updating a resource I'm thinking 409 Conflict, or maybe 403 or 400? Is there any convention or standard for this? Also, the body of the error response could be more XML-like, as was pondered in my blog post: http://toolmantim.com/article/2006/8/30/ correct_http_status_codes_and_responses Keen to know your thoughts. -- tim *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] REST HTTP error codes and responses for form/parameter validation
On 05/09/2006, at 11:37 AM, Matthew Cruickshank wrote: Is there any convention or standard for this? Not that I've found. The Yahoo's web services API documentation says that "400: Bad request. The parameters passed to the service did not match as expected" which seems about right for missing parameters. http://developer.yahoo.com/search/errors.html Interestingly this is the same approach as the REST client in Rails, which expects a "400 Bad Request" for validation errors: http://dev.rubyonrails.org/changeset/5068 REST obviously lends itself to HTML forms as API documentation (textareas, select boxes, etc.), so I've been providing that and returning HTTP status codes and XHTML. My CSS classes are exception names for machines to parse (though I should also include them as http X-something headers; and it would probably be better to send XML+client-side-XSLT rather than XHTML). I guess if they were expecting a HTML response then a "200 OK" with XHTML would be best (so you can test with forms), but if they wanted XML then you could return a "400 Bad Request". Do browsers render the response from 400 responses? I'd prefer to always be sending the same response code, it just feels wrong to be varying response codes depending on the accept header. -- tim *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] REST HTTP error codes and responses for form/parameter validation
On 04/09/2006, at 7:30 PM, James Ellis wrote: The RFC for this is at ftp://ftp.isi.edu/in-notes/rfc2616.txt via http://www.w3.org/Protocols/#Specs which includes the available codes in the Spec. Yep though its a shame that within a given domain the status code definitions are so vague that the spec is useless as a standard between developers, driving most people to just stick to 200 or 400 for everything. I think you could use 409 Conflict for invalid data. Maybe even 410 Gone if a client interacts with the resource no longer there.. etc etc. If found this in google: http://www.oreillynet.com/onlamp/blog/2003/12/ restful_error_handling.html One of the ideas there is to use an extra header to denote a more specific error I love that idea. Maybe just return "400 Bad Request" for validation errors with some extra headers for domain specific info? So you could have something like this which would allow you to target the actual error... HTTP/1.1 409 Gone X-API-Error 1500 Record foo no longer available 1500 record foo is no longer available The current Rails approach for validation errors when trying to create resources is to return "400 Bad Request" with the following response: Password confirmation can't be blank Password is too short (minimum is 4 characters) Password can't be blank Login is too short (minimum is 3 characters) Login can't be blank Email is too short (minimum is 3 characters) Email can't be blank It could definitely be improved by at least including the resource attribute the error relates to: Password confirmation can't be blank Password is too short (minimum is 4 characters) Password can't be blank Login is too short (minimum is 3 characters) Login can't be blank Email is too short (minimum is 3 characters) Email can't be blank -- tim *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
