「計画の制限を超えました」応答の推奨HTTPステータスコード

ユーザーが常にいくつかの「プラン」のいずれかを使用するプロジェクト用のREST APIを設計しています。各プランは、アカウントに含めることができるユーザーの最大数やアップロードできるデータの最大数など、リソースの制限を定義します。これらの制限の1つに達すると、ユーザーはプランをアップグレード（基本的に支払い）して、より多くのリソースを取得できます。

アカウントのリソース制限のためにアクションを実行できない状況を示す特別なステータスコードを返します。プランをアップグレードすると解決します-たとえば、ユーザーがストレージ容量の100％を使用して追加のファイルをアップロードしようとした場合、彼らはこの応答を受け取ります。

候補者は次のとおりです。

• 403 Forbidden -ただし、このケースと、ユーザーがこのアクションを実行するための許可を単に持たない他のケースとを区別したいと思います。

• 401 Unauthorized -良いアイデアではありません。認証関連の問題にこれを使用しています。

• 402 Payment Required -ある意味理にかなっていますが、標準ではないが予約済みのステータスコードの使用が心配です

• 423 Locked将来的には他のものに使用する可能性が低いため、さらに標準以下のもの

別のオプションは、非常に標準的なもの403を使用することです。ただし、応答本文にエラーの詳細を示します。

どのアプローチが（a）長期的に最も効果的であり、（b）RESTfulな原則にもっとうまく適合すると信じているのか疑問に思っています。

403が唯一の合理的な応答であると思いますが、405 Method Not Allowedまたは409 Conflictは許容されるかもしれませんが、403ほど優れているとは思いません。

サーバーはリクエストを理解しましたが、それを実行することを拒否しています。承認は役に立たず、リクエストは繰り返されるべきではありません。要求メソッドがHEADでなく、サーバーが要求が満たされなかった理由を公開したい場合、エンティティの拒否の理由を記述する必要があります。

403エラーを返す場合、リソースが拒否された理由に関する情報が含まれます-無効なアクセス許可は最も一般的なケースであり、制限を超えてもそれほど違いはありません-制限を超えたためアクセス許可がありません。

私は403が間違っていると信じています、403はあなたがリソースにアクセスしていない状況のためであり、アクセスする方法がまったくないからです。あなたの顧客にとって、明らかにアクセスする方法があります：支払い。

401は本当に間違っています。なぜなら、401を認証に使用しているだけでなく、それがそこにあるからです。

APIを書いているので、他の誰かがAPIを使用するコードを書く必要があり、その人はあなたのAPI仕様を読む必要があると思います。429「リクエストが多すぎます」で行くかもしれません。これは通常、レート制限（クライアントが1日に100件のリクエストを行うことができる場合など）を目的としていますが、状況に合理的に適用されます。402（支払いが必要）も許容されるでしょう。ユーザーがAPIを使用するのにどのツールを使用するかによって異なります。429には、巧妙なツールが1分/時間/日あたりの送信要求を少なくしようとして成功しないというリスクがあります。

ところで、https： //tools.ietf.org/html/rfc6585によると、429エラーには問題の性質を説明するhtmlメッセージも含まれている必要があるため、ユーザーが実際に問題が何であるかを伝えられる可能性が高いあなたの応答のその情報。

WebDAVはこれにHTTP 507 Insufficient Storageを使用し、他の種類のストレージ制限と区別するために、リクエスト本文にクォータ超過の追加エラーコードを含めます。