HTTP/1.1 狀態碼 400 和 417，不能選擇哪個
我有一個處理文件來處理使用者發送的數據，但是，在此之前，它將來自客戶端的輸入與預期值進行比較，以確保沒有客戶端數據更改。
我可以說我對 HTTP 狀態碼了解不多，但我已經對它進行了一些研究，並選擇哪一種最適合意外輸入處理。所以我想出了：
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現在，我不能確定要使用哪一個，我已經看到 400 Bad Request 被大量使用，但是，我從解釋中得到的是錯誤是由於不存在的請求而不是非法輸入造成的。
另一方面，417 Expectation Failed 似乎正好適合我的使用，但是，我以前從未見過或嘗試過這種標頭狀態。
我需要你的經驗和意見，非常感謝！
有關表單/流程頁面草稿和我的實驗的完整詳細資訊，請點擊此連結。
補充：另一個原因——我想要這個是為了防止Google操縱。這不僅用於後端，還用於顯示訪客/使用者互動以及要呈現頁面內容的前端。
我相信*，給出 200 OK 或 403 Forbidden 狀態程式碼對於存在或允許存在的頁面有效。
*補充二：我現在查看了 417 和 100，發現它們與我嘗試做的類似（至少僅用於上傳處理案例），在這裡： http ://benramsey.com/blog/ 2008/04/http-status-100-繼續/
- 即： *連結到 X 站點的網頁http://www.example.com/page.php?query=lol&query2=fail將被 Google 索引，因為 HTTP 標頭被指定為 OK。
我來到的解決方案：
確實 404 是我可能再次結束的。我只是想要一個不同的解決方案，如果 HTTP 提供了它，但到目前為止，404 似乎仍然是最好的解決方案，謝謝大家，我的問題已經找到了答案。
如果 GET 請求的參數不正確，規範的做法是發回 404（未找到）或 200（OK）。
使用 GET 請求的 RESTful 方式是查詢資源（獲取某些東西）。因此，如果所需的參數與現存資源不對應（因為它們不完整），則可以準確地說在URI中查詢的資源未找到。
實際上，如果您想避免瀏覽器忽略您的 404 頁面並替換它們自己的頁面（我正在查看 IE 9 和 10），您可能希望使用 200。如果您認為您的應用程序是資源，則 200 是合適的；您查詢了應用程序，它返回了一個結果（這恰好是一個錯誤，但不是在 HTTP 級別）。但是，這種用法不是很 RESTful。