HTTPステータスコードを使用して特定のエラー状態をクライアントに通知したいとします。416などのHTTPステータスコードを再利用できますか？
最も近いのは "416 Range Not Satisfiable"ですが、サービスはファイルからバイト範囲を提供することとは関係ありません。
"Range Not Satisfiable"の意味を自由に解釈できますか、またはファイルのバイト範囲に関連する技術的定義を尊重する必要がありますか？
お客様はそれを自由に解釈します。しかし、それは正しいことにはなりません。
現在の4xxで特に処理されないエラーは、一般的に400というエラーが表示され、その理由が説明されています。一般的な規則は、エラーが特定のコードと完全に一致する場合はそれを使用し、それ以外の場合は特定しないコードを使用することです。
特定のコードの意味がオーバーロードされると、大量の混乱を招く可能性があります。
RFC7231, section 6.5 1として（私のイタリック体）：
の4xx（クライアントエラー）ステータスコードのクラスは、クライアントが誤りを犯しているように見えることを示しています。 HEAD要求に応答する場合を除いて、サーバは、エラー状況の説明であるを含む表現を送信し、一時的または永続的な条件であるかどうかを送信すべきである（SHOULD）。これらのステータスコードは、任意のリクエストメソッドに適用されます。ユーザエージェントは、含まれている表現をユーザに表示すべきである（SHOULD）。
問題は、一連のプロキシ、APIゲートウェイなどがある場合、他の理由でさまざまな表現で400コードを返すことができます。クライアントが応答をより簡単に解釈できるように、特定のURLのサービスから明白に推測できるステータスコードを使用したいと思います。 – aaa90210
@ aaa90210の場合は、IETFに参加して、 '499特定のコードをaaa90210に割り当てて、コード作成の労力を最小限に抑える'コードを追加するよう説得します:-)他にも多くのクラウドが以前に行ったように（https://en.wikipedia.org/wiki/List_of_HTTP_status_codes）。レスポンス本体に*非常に*特定のメッセージを挿入するのは簡単なことです。コードやユーザが簡単に解釈できるもの（ 'ERR314159 - no peeking allowed'など）です。 – paxdiablo
Seconded。ウェブから。 RFC 7233を参照してください。 – VoiceOfUnreason
レスポンス本文（またはエラーメッセージ行）に詳細な情報を含めると、一般的な「不良リクエスト」ステータスコードを使用する方がよい。 – Thilo