間違った入力に対する正しいHTTPステータスコード
200（すべてOK）ではなく、入力エラーを報告する場合の最適なHTTP応答コードは何ですか？
たとえば、サーバーにデータを送信すると、データが間違っていると応答します
500を使用すると、サーバーの問題のように見えます200を警告/エラーレスポンステキストと共に使用するのは不適切です（キャッシュを許可し、すべてが正常ではありません）204を使用して何も返さないのは良いかもしれません（しかし、十分にサポートされていますか？）
要求されたパス（スクリプト）が適切な場所にある場合、404を使用するのは間違っています
APIを作成するときにも同じ問題がありました。 InvalidArgumentExceptionと同等のHTTPステータスコードを探していました。以下のソース記事を読んだ後、私たちは422 Unprocessable Entityを使用することになりました。
422（Unprocessable Entity）ステータスコードは、サーバーがリクエストエンティティのコンテンツタイプを理解し（したがって、415（サポートされていないメディアタイプ）ステータスコードが不適切）、リクエストエンティティの構文が正しいことを意味します（したがって、400（Bad Request ）ステータスコードは不適切です）が、含まれている指示を処理できませんでした。たとえば、XML要求本文に整形式（つまり、構文的に正しい）であるが、意味的に誤ったXML命令が含まれている場合、このエラー状態が発生する可能性があります。
ソース： https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm
4（4xx）で始まるコードは、クライアントエラーを対象としています。たぶん400（Bad Request）がこのケースに適しているでしょうか？ http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html の定義：
「不正な構文のため、サーバーがリクエストを理解できませんでした。クライアントは、変更せずにリクエストを繰り返すべきではありません。」
RFC Spec に加えて、これも実際に動作していることがわかります。 TwitterとFacebookの回答をご覧ください。
https://developer.Twitter.com/en/docs/ads/general/guides/response-codes
http://www.fb-developers.info/tech/fb_dev/faq/general/gen_10.html
409 Conflictは許容可能なソリューションです。
によると https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
リソースの現在の状態と競合するため、要求を完了できませんでした。このコードは、ユーザーが競合を解決してリクエストを再送信できることが予想される場合にのみ許可されます。応答の本文には、ユーザーが競合の原因を認識するのに十分な情報を含める必要があります。理想的には、応答エンティティには、ユーザーまたはユーザーエージェントが問題を修正するのに十分な情報が含まれているはずです。ただし、それは不可能な場合があり、必須ではありません。
ドキュメントの例は次のとおりです。
競合は、PUT要求への応答で発生する可能性が最も高くなります。たとえば、バージョニングが使用されており、PUTであるエンティティに以前の（サードパーティ）リクエストによるものと競合するリソースへの変更が含まれている場合、サーバーは409応答を使用してリクエストを完了できないことを示すことがあります。この場合、応答エンティティには、応答のContent-Typeで定義された形式の2つのバージョンの違いのリストが含まれる可能性があります。
私の場合、APIを介してデータベースに対して一意でなければならない文字列をPUTしたいと思います。データベースに追加する前に、データベースにまだないことを確認しています。
そうであれば、"Error: The string is already in the database", 409を返します。
私はこれがOPが望んだものだと信じています：データがサーバーの基準を満たさない場合に適したエラーコード。