This is something which is not exactly a Rails issue, just something Rails (as well as most of the other frameworks including jQuery library) contribute to.
Let’s consider I have a form which creates a resource on my web-client. It posts the form on submission to a “create” endpoint on a certain controller. If the resource can be created, it responds with status code 201 (Rails actually attributes 200, why?), if the resource can’t be created because it doesn’t validate, it responds with 4xx status code (I don’t remember what Rails returns as status code in this case, but since there is no standard, whatever). This is the scenario I see when I handle plain synchronous HTTP requests.
Now, let’s say I want to Ajaxify my form. I handle the form submission assynchronously and what not, and the same resource validation handling happens in the server. And now it’s where it gets tricky. Rails per convention always responds with status code 200, whether the resource has been created or not. That I find odd.
But then again, Rails is not alone in this. jQuery only evaluates the body of its $.ajax request responses only if the request was successful (200). It’s true Rails is jQuery-independent, but it tends more and more, since abandoning prototype, to play to its strengths. Hence, the web-frameworks (not only Rails, I’d say, feel free to list other frameworks that do it) have conveniently “standardized” the js response status code handling, I’d say.
What do you think about this? Am I being too picky? For me, a good way of handling these specific 4xx error responses would be to check the response content-type header; if it’s the same as requested, then it should be executed; if it ain’t, then it’s probably something we don’t want to handle on the client side. Of course, I’m not forgetting one lists the response formats per order of preference on the Accept request header, but this is just a suggestion for a possible discussion.