On Tue, Aug 19, 2008 at 11:17 AM, Jorge Vargas <[EMAIL PROTECTED]> wrote: > > On Tue, Aug 19, 2008 at 1:08 AM, Lawrence Oluyede <[EMAIL PROTECTED]> wrote: >> >> On Tue, Aug 19, 2008 at 8:20 AM, Sok Ann Yap <[EMAIL PROTECTED]> wrote: >>> Returning 400 for form validation error is recommended by Leonard >>> Richardson and Sam Ruby in the book RESTful Web Services. Here's an >>> excerpt from one of the examples in the book >> >> Also if they didn't say it... it's just that 200 OK is plain wrong to >> signal an error condition. >> That's what 4xx and 5xx codes are for. >> > Even though I agree in principle, there is no 4xx code to signal an > "error in the value of the parameters", please remember that http is a > transport protocol, and from that perspective it was a successful > transfer. I believe that trying to return http status codes for > application logic is violating the TCP layer division that has held us > in place for so long.
I disagree. TCP is the transport protocol (which resides at the transport level of the stack). HTTP is an application protocol (which resides on top of the stack), and I'm pretty sure that the creators of HTTP intended to use 400 BAD REQUEST also for such cases. As the spec says: " The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. " Nothing forbids to explain _why_ in the body of the response but if you want to create a seamless web where 200 means "ok what you asked worked correctly" returning 200 for an error is not the most compatible way to go. Remember also there are automatic clients, non-desktop-web clients, mobile browsers and so on. If you want maximum compatibility I think that returning an error code for an error situation is not also smart to do but should be mandatory. There is really no point in returning a OK status code with something that didn't go as it should. Imagine a situation when I do subsequently PUT of a resource like /book/summer. If the server replied 200 with a wrong content (or wrong content type) how do I know that I'm doing something wrong? Looking at the body searching for the "error" word is not feasible, that's what status codes are for. > Building up on the json example, it should be read as, the request was > successful and everything when ok (http:200) now it seems you fail > with supplying the correct values (statusCode:xxx) So the request did not suceed because the GOAL was not to test that the server is there and alive but that the next time I access to the resource it will be there. Not that I'll found out in 10 minutes that the request I made 10 minutes ago didn't work altough the server told me it did. That's quite byzarre. > as for the webservices reference, I don't think that applies to > web-browsers, they could even interpret the 400 as something totally > different. Web browser are web clients of web services. There shouldn't definitely be a difference in status codes among which kind of client I could get. There can be a difference in response format (based on Accept or suffixes) but it's insane to return different status codes based on the UserAgent. It reminds of the old day of UA sniffing to render different pages. My suggestion is to read something about HTTP and REST in general. Why bend the rules when these are the basic scenarios where HTTP shines? I can be wrong about the correct status code but returning 200 for an error situations is asking for troubles and asking for more and more work for the people who needs to access that web service in the future: be that a browser, a programming language, a mobile phone or whatever. Some web standards are so good because if you do things correctly they can last and work with clients that are nowhere but in the minds of future developers. -- Lawrence, stacktrace.it - oluyede.org - neropercaso.it "It is difficult to get a man to understand something when his salary depends on not understanding it" - Upton Sinclair --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
