rich97
rich97

Reputation: 2879

What's the appropriate HTTP response for invalid data submitted by the user?

I'm experimenting with JSON and http response codes. I'm submitting a form via an AJAX request and I obviously need to validate the data on the server-side.

My idea is to respond with a "200 OK" response (with a confirmation message as the body) if the post is successful. I don't know what to respond with if the data that the user sends is invalid.

Upvotes: 7

Views: 6701

Answers (7)

Marc B
Marc B

Reputation: 360702

Send back a 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 with a service in this way. Fiddling with HTTP status codes doesn't seem right, as EVERYTHING about the actual HTTP request itself worked fine - it's just that the request didn't conform to the service's expectations.

Upvotes: 7

jfriend00
jfriend00

Reputation: 707466

The way I typically see this done is that you let the HTTP response codes be used for things related to the HTTP protocol, not for your application errors. Then, from your HTTP response, you return JSON that indicates success or failure and any desired returned data. For example, you could 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 that looks at the response looks first at the statusCode and depending upon whether that is successful or not, it looks for other data.

If you imagine how this response will be used by the caller, I find it valuable to have different code paths for application level errors vs. transport level errors. If you think about a jQuery.ajax() call. The success handler will be called when the http status code is a successful code. The error handler will be called when the http status code is not successful. Doing it this way, you can have generic error handlers for all transport level errors with one ajax error handler and then you can put your specific application-level error handling in the success handler by examining the application level status code in the returned JSON. If you go with the error 400, then you have to code up a whole different error handler for each ajax call to deal with both the transport errors and the application level errors.

Upvotes: 0

Julian Reschke
Julian Reschke

Reputation: 42035

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

Upvotes: 0

ircmaxell
ircmaxell

Reputation: 165201

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

Request:

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

Response:

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

And on error:

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

It's quite flexible, and is standard...

Upvotes: 7

johndodo
johndodo

Reputation: 18281

Depends on the purpose of API. If it's yours (private) then answer with HTTP status 400 as Nightfirecat suggested. If it's a public API send a meaningful error message to aid developers.

Upvotes: 1

David Z
David Z

Reputation: 131600

Here's the complete list of HTTP status codes. The first one that springs to mind for your situation is 400 Bad Request, but that's usually used to indicate an error in the HTTP syntax rather than an error in the body content. Still, without more information I'd go with that one.

In specific cases, depending on the exact nature of the data you're receiving, I could see any of 403, 404, 410, 413, or perhaps others being the appropriate response.

Upvotes: 1

Nightfirecat
Nightfirecat

Reputation: 11610

You could send a 400: Bad Request header. If that's not your cup of tea, maybe check through the W3C's Status Code Definitions?

Upvotes: 13

Related Questions