HTTP/1.1 Status Codes 400 and 417, cannot choose which

Solution 1:

If the parameters for a GET request are incorrect, the canonical thing to do is send back either a 404 (not found), or 200 (OK).

The RESTful way to use GET requests is to query a resource (get something). Therefore, if the required parameters don't correspond to an extant resource (because they are incomplete), you can accurately say the resource as queried in the URI is not found.

Practically, if you want to avoid things like browsers ignoring your 404 page and substituting their own (I am looking at IE 9 and 10), you may want to use 200. If you consider your application to be the resource, 200 is appropriate; you queried the application, and it returned a result (that happened to be an error, but not at the HTTP level). However, this use is not very RESTful.

Solution 2:

The 417 error should only occur when the client sent an HTTP Expect header that the server could not fulfill, which doesn't relate in any way to the application's "expected inputs" in the request. Do not use it.

On the other hand, a 400 error should be sent only when there is bad syntax in the HTTP request that the server doesn't understand.

Neither of these is really appropriate for a validation failure in application logic, though I suppose 400 is a little more appropriate.

The 403 error that you were contemplating using in your question over on Stack Overflow is the best option in my opinion.

I just used 403 Forbidden header when the expected values weren't found in the $_GET, but, when thought for, it isn't really an action that requires login(not for this, ofcourse a user have to login to view the admin panel in the first place), it's more like an unexpected value input.

You're thinking of 401, which is the response code that's utilized when authentication is needed. 403 is a generic deny of the request, which sounds like exactly what you want.

This all assumes that you want to return a 4xx response code.. which makes sense for an API.. but for a user-facing HTML page, you'd more likely want to send a 200 with the error information in the body.

Solution 3:

I can't quite figure out what your doing however there is an additional option that you may not have considered - 200 - OK. The reason is that you received the data correctly the problem is it's not valid for your application which isn't really a problem with the HTTP protocol.

The relevant rfc here is rfc2616. You could use 400 but you then need to provide the client the ability to modify the data, from the rfc

10.4.1 400 Bad Request

The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

Regarding the 417 the rfc says

10.4.18 417 Expectation Failed

The expectation given in an Expect request-header field (see section 14.20) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could not be met by the next-hop server.

so if you're not using the expect header you probably shouldn't use this response.