9

I am creating a feature of my web application where a user can "edit-in-place" a record and submit the form via AJAX using jQuery.

When someone is "ajax editing" a record and they submit the form with valid data, I send a 200 status code, which triggers the jQuery AJAX Success function, then ignore the response body (since it was successful, I don't need it), and collapse the form.

When there are form validation errors, I send a 400 status code in order to trigger the jQuery error method, and in the body of the request I specify which fields did not validate.

In a previous StackOverflow question, someone mentioned that it "seemed odd" that I was sending a 400 status code and working with the response body. Is my approach not a best-practice? What would you recommend that I do in this situation?

Andrew
  • 227,796
  • 193
  • 515
  • 708

3 Answers3

9

For me, HTTP status codes are for signalling at the HTTP layer, not the application layer. I would say the appropriate response to bad data properly submitted (if you see what I mean) is a 200 with an application-layer error code. I use JSON for this. My requests always get back a small JSON message, which always has a flag indicating success/failure at the application level. My wrappers for ajax calls know about this and dispatch as appropriate.

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
  • good point. so is your json kind of like this: {success:0, html:'error messages go here'} – Andrew Jul 15 '11 at 00:09
  • 1
    @Andrew: Yes, or `{"error": ""}` on success and `{"error": "Non sequitur. Your facts are uncoordinated."}` on error. Then my client-side code is `if (message.error) { /* ...report error */ }` – T.J. Crowder Jul 15 '11 at 00:13
  • 3
    I don't agree. In REST-style interfaces the response codes are for application level signalling. Think about CRUD operations where you return say 201 CREATED on a POST. In this case a 400 is not a bad way to signal incorrectly formatted data. – Martin Algesten Jul 15 '11 at 00:25
  • That would mean abusing HTTP as a tunnel. Don't. – Julian Reschke Jul 15 '11 at 07:48
  • @Julian: HTTP **is** a tunnel for my apps. I'm not writing a WebDAV client or server. Moreover, the defined set of response codes don't cover the full range of errors for an application (as opposed to a resource locator/provider), and while [the spec specifically says they're extensible](http://tools.ietf.org/html/rfc2616#section-6.1.1) and so I could use 471 to mean "Your facts are uncoordinated," I'm reluctant to trust every link in the chain behaving properly, "MUST" in the spec or no. – T.J. Crowder Jul 15 '11 at 08:29
  • Hi @T.J.Crowder - What a coincidence to see your name for the second time today, but for a totally different subject. I have just posted a similar question to this one, [here](http://stackoverflow.com/questions/10253732/how-to-handle-expected-error-in-ajax-including-disclosing-them-to-user). I kinda share your view regarding this problem but then I still can't make up my mind. Can you please comment on it when you get a chance? Thank you. – tamakisquare Apr 20 '12 at 22:46
5

Using the payload of a 4xx status code is just fine. There's nothing in the HTTP spec saying otherwise.

If you want something more specific than 400, have a look at 422 Unprocessable Entity.

Julian Reschke
  • 40,156
  • 8
  • 95
  • 98
  • Status codes are really for communicating metadata about the request between client and server, not between application and server. – Alex Reynolds Jul 16 '11 at 00:55
  • 1
    422 is also a WebDAV extension to the HTTP protocol, not part of the original protocol. It would only make sense to use this status code with a WebDAV service. – Alex Reynolds Jul 16 '11 at 00:59
  • IMO using error 4xx codes for validation errors is correct in terms of HTTP specs. However, many libraries JS libraries assume you'll be returning 200 and on 4xx they are like "it's FUBAR-ed, let's go home.". For example PJAX will display content only if it comes with success code. Sending proper error codes was always an uphill struggle in my experience. Now I'm leaning towards just sending validation errors with code 200. – Wojtek Kruszewski Jun 28 '13 at 08:07
  • 1
    I use 409 for validation errors:- "This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request" http://www.restapitutorial.com/httpstatuscodes.html – rgvcorley Sep 20 '13 at 12:22
-1

I would return 200 with an (application) error page, or the original page with an error option, which triggers an informational panel with the error description.

The reason for this is that the HTTP error codes are for the browser's response to the web server, not for your web application. Keep your application logic separate from what happens when the browser and server talk to each other.

Alex Reynolds
  • 95,983
  • 54
  • 240
  • 345
  • Consider you have your Main Application, which in turn contains two applications: 1. A whole JS application that will consume your second application. 2. An API that will be consumed by your JS application. Why don't to use HTTP response codes to handle success or error callbacks? What if more clients start consuming your second application?, if that was the case and you did start correctly sending HTTP response codes from start, then you wouldn't have to refactor the responses from your API. My point here is that it doesn't hurt to use different HTTP response codes. What do you think? – chischaschos Oct 24 '12 at 16:01