提供されていない必須パラメーターに使用するHTTPステータスコード
AJAXで呼び出すように設計されたいくつかのページがあります-表示できない場合、異常なステータスコードを返します。それに応じて、javascriptにエラーボックスが表示されます。
たとえば、ユーザーが認証されていないか、セッションがタイムアウトし、AJAXページのいずれかを呼び出そうとすると、401 Unathorized。
戻り値もあります500 Internal Server Error本当に奇妙なことがサーバー側で発生した場合。
これらのページの1つが必須パラメーターなしで呼び出された場合、どのステータスコードを返す必要がありますか？ （したがって、コンテンツを返すことはできません）。
HTTPステータスコードに関するウィキペディアの記事 を見ましたが、探しているコードに最も近いものは次のとおりです。
422 Unprocessable Entity
リクエストは整形式でしたが、セマンティックエラーのために追跡できませんでした。
編集：上記のコードはWebDAV固有であるため、この場合には適切ではない可能性があります
誰もが返す適切なコードを考えることができますか？
これらのページの1つが必須パラメーターなしで呼び出された場合、どのステータスコードを返す必要がありますか？ （したがって、コンテンツを返すことはできません）。
404 Not Foundを選択できます：
サーバーは、Request-URIに一致するものを見つけられませんでした[必要なパラメーターがURIの一部である場合、つまり
$_GET]。状態が一時的なものか永続的なものかは示されていません。 410（Gone）ステータスコードは、サーバーが内部で構成可能なメカニズムを介して、古いリソースが永続的に使用不可であり、転送アドレスがないことを知っている場合に使用する必要があります。このステータスコードは、サーバーが要求が拒否された正確な理由を明らかにしたくない場合、または他の応答が適用できない場合に一般的に使用されます。
（私によるハイライト）
404 Not Foundは400 Bad Requestのサブセットです。これは、これが何であるかについて非常に明確であるため、同様に取得できます。
構文が正しくないため、サーバーがリクエストを理解できませんでした。クライアントは、変更せずにリクエストを繰り返すべきではありません。
ハイパーテキストを使用してHTTPクライアント用に存在しないWEBDAV応答コードを選択することは実際にはお勧めできませんが、それは完全に有効であり、サーバーコーダーであり、適切なHTTP応答ステータスコードを実際に取得できますあなたがデザイナーでもあるHTTPクライアントの場合：
11.2。 422処理できないエンティティ
422（Unprocessable Entity）ステータスコードは、サーバーがリクエストエンティティのコンテンツタイプを理解し（したがって、415（Unsupported Media Type）ステータスコードが不適切）、リクエストエンティティの構文が正しいことを意味します（したがって、400（Bad Request ）ステータスコードは不適切です）が、含まれている指示を処理できませんでした。たとえば、XML要求本文に整形式（つまり、構文的に正しい）であるが、意味的に誤ったXML命令が含まれている場合、このエラー状態が発生する可能性があります。
IIRC要求エンティティは要求本文です。そのため、リクエスト本文を操作している場合、Julianが書いたように適切な場合があります。
コメントしました：
IMHO、400のテキストは不正な構文について語っています。ここでの構文は、クライアントがサーバーに送信するHTTP文字列の構文に関連すると仮定します。
それは可能ですが、構文的に表現されたもの、リクエスト全体、一部のリクエストヘッダーのみ、または特定のリクエストヘッダー、リクエストURIなどです。400「HTTP文字列構文」に関するものではなく、一般的な答えです。クライアントエラー：
ステータスコードの4xxクラスは、クライアントが誤っているように見える場合を対象としています。 HEADリクエストに応答する場合を除き、サーバーは、エラー状態の説明と、それが一時的な状態か永続的な状態かを含むエンティティを含める必要があります。これらのステータスコードは、すべてのリクエストメソッドに適用できますユーザーエージェントは、含まれているエンティティをユーザーに表示する必要があります。
ここで重要なのは、クライアントに何が悪いのかを伝える必要があるということです。ステータスコードは、（4xxクラスで）何かがうまくいかなかったことを伝えているだけですが、HTTPは、欠落したquery-infoパーツパラメーターをエラー状態として認識できるように特別に設計されていません。実際、URIはquery-info部分があることだけを知っており、それが何を意味するのかを知っていません。
400が広すぎると思う場合、問題がURI関連の場合は404を選択することをお勧めします。 $_GET変数。
RFCライターの意図については知りませんが、そのケースで使用されている状況コードは400 Bad Requestです。
422は通常のHTTPステータスコードです。そして、itisはWebDAVの外部で使用されます。他の人の言うことに反して、それは問題ありません。 HTTPには、理由のためにステータスコードレジストリがあります。
400に対して引用された説明
不正な構文が原因で、サーバーは要求を理解できませんでした。クライアントは、変更せずにリクエストを繰り返すべきではありません。
（エンファシス鉱山）
これは、ブラウザがサーバーにリクエストを送信する場合には当てはまらない、不正な形式の構文について語っています。パラメータが欠落している場合にのみ当てはまります（ただし、不正な構文はありません）。
私は404に固執することをお勧めします:)
（私がどこでも間違っている場合、専門家は私を修正します:)）
これを注意深く読んでください：
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
422はWebDAV固有のものであり、他の用途には使用されていません。
400は、この特定の目的のためではありませんが、一般的な選択のようです。
404は、APIがRESTfulまたは類似している場合にも実行可能な選択肢です（URIのパス部分を使用して検索パラメーターを示す）