次の状況に適した HTTP ステータス コードを知っている人はいますか?
匿名クライアントは、GET /collection/?range_start=100&range_end=200. 例のクエリは、100 個のアイテムを含むリストを (JSON で) 返します。また、クライアントが要求できる項目の数には、たとえば 300 などの制限があります。クライアントがたとえば範囲 [100, 1100] の 1000 アイテムを要求した場合、応答ステータス コードは何になるべきですか? 700 アイテムが制限を超えていることを意味します。
400 Bad Request、403 Forbidden、409 Conflict、416 Requested Range Not Satisfiable(?)、または 422 Unprocessable Entity である必要がありますか? あなたは何をお勧めします？
関連する質問と回答では 409 が提案されていますが、状況は少し異なります: https://stackoverflow.com/a/13463815/638546
403 が最も適切な選択肢のように思えます。それは基本的に「ええと。あなたはそれを見ることができません。」と言っていますが、これはほとんどの場合です。
10.4.4 403 禁止
サーバーは要求を理解しましたが、要求を満たすことを拒否しています。 承認は役に立たず、要求を繰り返すべきではありません。[...]
もちろん、リクエストを拒否する理由をレスポンスボディに含めることをお勧めします。
他のすべてのコードには、ここでの使用を不適格とする特定の意味があるように思えます。
400は、リクエストが有効であるため適切ではありません。一度に送信したい以上のものを要求しているだけです。
409は、特にリソースの「状態」に関連しているため、適切ではありません。（リンクした質問には適切です。その場合、エラーはすでに「いっぱい」だったコレクションに追加されていたからです。ただし、あなたの場合、問題があるのはリソースではなく、リクエストです。）また、
このコードは、ユーザーが競合を解決してリクエストを再送信できると予想される状況でのみ許可されます。
ここで、「再提出」とは、標準が「繰り返す」ことを意味します。この場合、クライアントが何をしても、そのリクエストは無効になります。
416は特に「Range」ヘッダーを参照するため、完全にアウトです。
417も同様にヘッダー フィールド (この場合は "Expect") を参照するため、同様にアウトです。
422は適切ではありません。これは、構文的には正しいエンティティを送信したことを明確に意味するためですが、それでも壊れています。GET には伝統的にリクエスト ボディがない (エンティティがない) ため、処理できないものは何もありません。クライアントがリクエストを POST している場合は、ほとんどケースがあるかもしれません...しかし、RESTful API が何も更新しない POST を必要とする理由についても、適切なケースを作成する必要があります。
(コードが WebDAV 以外ではあまり意味をなさないことは約 47% 確信しています...しかし、考えられるユースケースがあるようです。これは違います。)
これにより、常に400シリーズのクライアントエラーが発生します。正確にどのエラーがAPI/CGI開発者の選択によるものか。405、406、416または「catch-all」417のいずれかを期待します。API開発者は、これらのエラーメッセージのテキスト（本文）を制御して、より有用な情報を含めることができます。