What is the appropriate HTTP response to invalid data submitted by the user?

Question

I am experimenting with JSON and http response codes. I submit the form via an AJAX request, and I obviously need to check the data on the server side.

My idea is to reply with the reply "200 OK" (with a confirmation message as body) if the message is successful. I do not know what to answer if the data sent by the user is invalid.

Answer 1

Just follow a standard protocol like JSON-RPC . It has error handling, parameter passing, etc.

Request:

{"method": "postMessage", "params": ["Hello all!"], "id": 99} 

Answer:

 {"result": 1, "error": null, "id": 99} 

And on error:

 {"result": null, "error": "Duplicate Message", "id": 99} 

It is quite flexible and standard ...

Answer 2

You can send the 400: Bad Request header. If this is not your cup of tea, perhaps check out the W3C Status Code Definitions ?

Answer 3

Send back the JSON object:

 $message = array( 'error' => true, 'code' => 'some error number relevant to you', 'message' => 'A nice human-readable+relevant error message' ); echo json_encode($message); 

I prefer signaling errors using the service this way. The script with the HTTP status codes does not seem to be correct, since ALL of the actual HTTP request worked fine - it's just that the request did not meet the expectations of the service.

Answer 4

Depends on the purpose of the API. If it is your (private), then respond with an HTTP status of 400, as suggested by Nightfirecat. If it is a public API, send a meaningful error message to help developers.

Answer 5

Here is a complete list of HTTP status codes. The first that comes to mind for your situation is 400 Bad Request, but it is usually used to indicate an error in the HTTP syntax, and not an error in the contents of the body. However, without further information I would go with this.

In specific cases, depending on the exact nature of the data you receive, I could see that any of 403, 404, 410, 413, or possibly others, is the appropriate answer.

Answer 6

As I usually see, this is done so that you allow the use of HTTP response codes for things related to the HTTP protocol, and not for your application errors. Then from your HTTP response, you return JSON, which indicates success or failure, as well as any returned data. For example, you can return this:

 { statusCode: 0, // 0 = successful, negative value = error code statusMsg: "success", // you can put any human readable status msg here data: { confirmationMsg: "Data sent successfully." } } 

Then your code, which looks at the answer, first looks at the statusCode and depending on whether it is successful or not, it looks for other data.

If you can imagine how this answer will be used by the caller, I find it useful to have different code paths for application-level errors and transport-level errors. If you are thinking of calling jQuery.ajax() . A success handler will be called when the http status code is a successful code. An error handler will be called when the http status code is not successful. That way, you can have common error handlers for all transport-level errors with one ajax error handler, and then you can put your application-level error handling in a success handler by looking at the application-level status code in the returned JSON. If you go to error 400, then you need to program a whole error handler for each ajax call to handle both transfer errors and application-level errors.

Answer 7

Either 400 (general), or if you want to be more specific: http://greenbytes.de/tech/webdav/rfc4918.html#STATUS_422