回答:
ステータス422は、仕様に基づいて最も適切と思われます。
422（Unprocessable Entity）ステータスコードは、サーバーがリクエストエンティティのコンテンツタイプを理解しているため（415（Unsupported Media Type）ステータスコードが不適切）、リクエストエンティティの構文が正しい（つまり、400（Bad Request ）ステータスコードが不適切）ですが、含まれている指示を処理できませんでした。たとえば、XMLリクエストの本文に整形式（つまり、構文的には正しい）が含まれているが、意味的には誤りのあるXML命令が含まれている場合に、このエラー条件が発生することがあります。
彼らは、不正なxmlが不適切な構文の例であると述べています（400を要求）。不正なクエリ文字列はこれに類似しているように見えるので、400は、パラメーターが欠落している整形式のクエリ文字列には適切ではないようです。
UPDATE @DavidVは、この仕様がコアHTTPではなくWebDAV用であることを正しく指摘しています。しかし、いくつかの一般的な非WebDAV APIは、ステータスコードが不足しているため、とにかく422を使用しています（これを参照）。
400より適切だと思います。
標準が設定されているかどうかはわかりませんが、最新のHTTP仕様（2014年から）が次のように文書化している400 Bad Requestを使用したでしょう。
6.5.1。400不正な要求400（Bad Request）ステータスコードは、クライアントエラーであると認識される何か（たとえば、不正な形式の要求構文、無効な要求メッセージのフレーミング、または不正な要求ルーティング）により、サーバーが要求を処理できないか、または処理しないことを示します。
400 Bad Requestセマンティックエラーではなく、プロトコルレベルの問題を示すことを目的としています。アプリケーションレベル（プロトコルレベルではなく）のエラーを示すためにHTTPステータスコードをハイジャックする場合は、どうしても最後まで使用し412ないでください。
.NET のWCF APIはHTTP 404、webHttpBindingの使用時に「Endpoint Not Found」エラーを返すことにより、欠落しているパラメーターを処理します。
404 Not Foundあなたはそのパラメータの署名と一緒にあなたのWebサービスメソッドの名前を考えた場合に意味をなすことができます。つまり、Webサービスメソッドを公開し、LoginUser(string, string)を要求してLoginUser(string)も、後者は見つかりません。
基本的に、これは、呼び出しているWebサービスメソッドと、指定したパラメーターシグネチャが見つからないことを意味します。
10.4.5 404が見つかりません
サーバーは、Request-URIに一致するものを検出しませんでした。状態が一時的であるか永続的であるかは示されません。
400 Bad Request、とゲルトが提案し、有効な応答コードのまま、私は通常より低いレベルの問題を示すために使用されていると思います。これは、不正な形式のHTTPリクエスト、HTTPヘッダーの欠落または無効などとして簡単に解釈できます。
10.4.1 400不正なリクエスト
不正な構文のため、サーバーはリクエストを理解できませんでした。クライアントは変更せずにリクエストを繰り返すべきではありません。
APIプロジェクトの1つで、409 Statusをいくつかのリクエストに設定することにしました。パラメーターが不足しているため、100％で完全に満たすことができない場合です。
HTTPステータスコード「409コンフリクト」は、ユーザーがコンフリクトの原因を認識するのに十分な情報を含める必要があるため、試してみました。
リファレンス：w3.org/Protocols/
そのため、400や404などの他の応答の中で、409を選択して、新しい適切な要求を設定するのに役立つ要求内のいくつかのメモを調べる必要を強制しました。
いずれにしても、リクエストが完全に正しくない場合はデータイブを送信する必要があり、クライアントにメッセージを見てリクエストのどこが間違っているかを理解させる必要があるため、これは特別なケースでした。
一般に、欠落しているパラメーターがいくつかしかない場合は、400と欠落しているパラメーターの配列を使用します。ただし、特定のケースメッセージなど、さらに多くの情報を送信する必要があり、クライアントが確実に処理するようにしたい場合は、409を送信します。
必要なパラメーターの何かがAPIエンドポイントが必要とするものと一致しない場合（短すぎるパスワードなど）、通常は422（処理できないエンティティ）を使用しますが、パラメーターがない場合は406（許容できない）を使用します。
Accept-Language: deおり、ドイツ語での応答のみを受け入れることを示していますが、サーバーで利用できるリクエストされたドキュメントのバージョンは英語またはフランス語のみです。）リクエストで欠落しているパラメーターを示すために使用すると、正しくありません。仕様の定義に従って。
この場合、Spring MVC（少なくとも3.x）は400を返しますが、これは私には間違っているようです。
私はいくつかのGoogle URL（accounts.google.com）をテストし、必要なパラメーターを削除しましたが、この場合、それらは通常404を返します。
Googleをコピーします。
404 Not Found指定されたリソースが見つからなかったため、a を使用する必要があると主張できます。
私はよく403 Forbiddenエラーを使用します。理由はリクエストが理解されたということですが、私は尋ねられたようにはしません（物事が間違っているため）。応答エンティティは何が問題なのかを説明するため、応答がHTMLページの場合、エラーメッセージはページ内にあります。JSONまたはXML応答の場合、エラー情報がそこにあります。
rfc2616から：
10.4.4 403 Forbidden
サーバーはリクエストを理解しましたが、リクエストの実行を拒否しています。
承認は役に立たず、リクエストは繰り返されるべきではありません。
リクエストメソッドがHEADではなく、サーバー
がリクエストが実行されなかった理由を公開したい場合は、エンティティで拒否の理由を説明する必要があります。サーバーがこの情報をクライアントに提供したくない場合は、
代わりにステータスコード404 （見つかりません）を使用できます。
Authorization will not helpが記載されているため、Twitterは無効なOAuth認証情報に対してこれを送信しないでください。
401 Unauthorized代わりに送信する必要があります。ただし、非常によく似ているこれらの2つのコードのMDNドキュメントの説明を見ると、なぜそうでないのか理解できます。
参照または例としてASP.NET Coreを使用するためだけに、ASP.NET Coreではアクションを使用してコントローラーを足場できます。これが「詳細」アクションの外観です。
// GET: Cars/Details/5
public async Task<IActionResult> Details(int? id)
{
if (id == null)
{
return NotFound();
}
var car = await _context.Cars.FirstOrDefaultAsync(m => m.CarId == id);
if (car == null)
{
return NotFound();
}
return View(car);
}パラメータidが設定されていない場合、404 Not Foundが返されます。
404を返します -つまり、リソースが見つかりませんでした。
IDを含むサイトのURLを編集してみてください。私はいくつか試しました：
これらの開発者は標準を正しく解釈しているので、すべてが404を返しますが、ここや他の多くの答えはそうではありません！
requestBody。
私は403で行きます。
RFC 2616から-ハイパーテキスト転送プロトコル-HTTP / 1.1
403禁止します
サーバーはリクエストを理解しましたが、リクエストの実行を拒否しています。承認は役に立たず、リクエストは繰り返されるべきではありません。リクエストメソッドがHEADではなく、サーバーがリクエストが実行されなかった理由を公開したい場合は、エンティティで拒否の理由を説明する必要があります。サーバーがこの情報をクライアントに提供したくない場合は、代わりにステータスコード404（見つかりません）を使用できます。
失敗の理由を回答で説明する必要があります。実行したくない場合は、404を使用してください。