What HTTP status should I use for when a POST parameter is missing?

Asked

Viewed 2,308 times

25

I have a form that will be submitted to the server via ajax, using a plugin for this. When the form is not filled in correctly (in case when a mandatory parameter is missing), I want to return a JSON with an error message and an error status, so that in javascript, the plugin enters the error callback instead of success.

I know you must be one of the 4xx family, but I don’t know which one.

Doesn’t seem to be any of those:

  • 400 - Bad request: the request worked, so much so that I returned a JSON

  • 404 - Not found: the feature exists, so much that I can give POST to it

  • 403 - Forbidden: I don’t think so either

What is the status I must return?

http http-status

  • Here you have all the codes, but I do not think there is an error for this, since there is no requirement for http q to be passed a post. You may want to default to 412. http://en.wikipedia.org/wiki/List_of_HTTP_status_codes

  • Laravel, PHP framework adopted the 422 by default, when there is any invalid data by request validation. Missing the parameter would be equivalent to violating validation required.

3 answers

22


The 422 is closest to this (I comment more about it).

In the 400, is talked about "bad syntax", but this is not the case (syntax error).

In the 412, is talked about "preconditions that the requester put on the request", that is, who contacted the server had a precondition. But this is also not the case, because it is the server (and not the requester) who will do the actual validation. Although, of course, it is possible to have some validation also on the form/client side.

In the 422, he talks about semantic errors. That is, there is no syntax error, but there is some information missing. It seems to be the most convenient.

16

  • 7

    I usually use 422 Unprocessable Entity: The request was well-Formed but was Unable to be Followed due to semantic errors.

8

Very interesting stack pointed by @Gypsy.

Particularly I support the use of 400 because the server would be responding that received a bad request from the client.

But why a bad requisition?

Because something he needs to provide the ideal and complete answer was missing. And that something can be, a URL argument (such as a token), a control field normally stored in a Hidden and etc.

  • Or the lack of an argument as a callback name in the case of JsonP :)

Browser other questions tagged http http-status

You are not signed in. Login or sign up in order to post.