I've got a processing file which handles the user sent data, before that, however, it compares the input from client to the expected values to ensure no client-side data change.
I can say I don't know lot about HTTP status codes, but I have made up some research on it, and to choose which one is the best for unexpected input handling. So I came up with:
400 Bad Request: The request cannot be fulfilled due to bad syntax
417 Expectation Failed: The server cannot meet the requirements of the Expect request-header field
Now, I cannot be really sure which one to use, I have seen 400 Bad Request being used alot, however, what I get from explanation is that the error is due to an unexistent request rather than an illegal input.
On the other side 417 Expectation Failed seems to just fit for my use, however, I have never seen or experimented this header status before.
I need your experience and opinions, thanks alot!
For a full detailed with form/process page drafts, and my experiments, follow this link.
Addition: One another reason-why I want this is to prevent Google manipulation. This will not only to be used in backend, but also in frontend where guest/user interaction will be shown and the page's content to be presented.
I believe*, Giving 200 OK or 403 Forbidden status codes are valid for pages that are existent, or allowed to be existed.
*Addition two: I've looked into 417 and 100 now, found that they're similiar to what I try to do (only for upload processing case, at least), in here: http://benramsey.com/blog/2008/04/http-status-100-continue/
- i.e: *A web page linking to the X site with http://www.example.com/page.php?query=lol&query2=fail would get indexed by Google since HTTP header is given as OK.
SOLUTION I CAME TO:
Indeed 404 is what I might be ending up with again. I just wanted a different solution than that, if HTTP provided it, but so far it seems 404 is still the best solution usable for this, thank you, all, my question has found it's answer.
Best Answer
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.