次の場合に適した応答コードとメッセージは何ですか。
- 間違った方法で送信されたフィールド(URLパラメーターと本文)または欠落しているフィールド
- 無効な値を取得するフィールド(数値の代わりに文字列、将来のタイムスタンプ)
?, /
URLパラメータのブレークなどの一部の文字- 実際の失敗:無効な資格情報、すでに実行されたアクションの繰り返し
現在、全部で400を使用しています。
質問のケース1、2、3は、基本的にリクエストの構文エラーです
=> 400不正なリクエスト
(RFC 2616によると:構文が正しくないため、サーバーは要求を理解できませんでした。)
ケース4について:
a。無効な資格情報
=> 401無許可
b。すでに実行されたアクションを繰り返す
=> 403禁止
(RFCによると:サーバーは要求を理解しましたが、それを実行することを拒否しています。承認は役に立たず、要求は繰り返されるべきではありません。)
しかし、409 Conflictと410Goneは、それぞれ誤って変更(PUT)しようとしたり、すでに削除されたリソースにアクセスしたりするときに意味があります。
そしてここにRFC2616セクション10があります。
各応答コードのHTTP仕様を読んで、応答本文に何を返すかについての情報を入手してください。たとえば、4xxは、「HEAD要求に応答する場合を除いて、サーバーには、エラー状況の説明と、それが一時的または永続的な状態であるかどうかを含む表現を含める必要があります」と述べています。
覚えておくべき主なポイントは、HTTP応答コードは均一になるように設計されているため、個々のアプリケーションの詳細なニーズを満たすよりも、相互運用性の促進に大きく関係しているということです。コードではなく応答本文を使用して、クライアントが理解できると期待する形式で詳細を含めます。
1つのフィールドが間違った方法で送信されたか(URLパラメーターと本文)またはフィールドがありません
「404NotFound」を返します。クエリ文字列パラメータはURIの一部であり、リソースを識別するために使用されます。/foo/bar?a=1&b=2
とは異なるリソースを識別しfoo/bar
ます。リソースが存在しない場合は、404を返します。コード内の同じロジックを使用して同じパスのクエリ文字列パラメーターを処理することは重要ではありません。これらの詳細は、統一されたインターフェイスの背後に意図的に隠されています。詳細については、URI仕様を参照してください。
無効な値を取得する2つのフィールド(数値の代わりに文字列、将来のタイムスタンプ)
ここでは、ユーザーが合理的に解決できる(そして要求を再送信できる)可能性があるという要求とリソースが競合する状態でない限り、400が最適です。その場合は409を返します。
3?、/URLパラメータの区切り文字などの文字
サーバーがクエリ文字列コンポーネントの予約文字を正しく処理していないことが原因でこのような破損が発生した場合は、500を返します。クライアントが不正な形式のRequest-URIを送信した場合は、400を返します。サーバーが処理しないリソースをURIが識別した場合は、404を返します。
4実際の失敗:無効な資格情報、すでに実行されたアクションの繰り返し
無効な資格情報は「401Unauthorized」になります。要求メソッドがべき等(GET、HEAD、PUT、DELETE)の場合、すでに実行されたアクションを繰り返すと、200 OK(またはリダイレクトなど)になります。POSTの場合、アクションの繰り返しはアクションの性質に完全に依存し、事実上すべてのステータスコードが返される可能性があります。400/409が一般的ですが、そのようなリソースの多くは単にアクションを再度実行するだけであり、これは多くの場合望ましいことです。