「計画の制限を超えました」応答の推奨HTTPステータスコード
私はRESTユーザーが常にいくつかの「計画」の1つにあるプロジェクトのAPIを設計しています-各計画は、アカウントが持つことができるユーザーの最大数や、アップロードできるデータの最大数これらの制限の1つに達すると、ユーザーはプランをアップグレード（実質的には支払い）して、より多くのリソースを取得できます。
アカウントのリソース制限が原因でアクションを実行できない状況を示す特別なステータスコードを返したい場合、プランをアップグレードすると問題が解決します-たとえば、ユーザーがストレージ容量の100％を使用し、追加のファイルをアップロードしようとした場合、この応答を受け取ります。
候補者は、私見です：
403 Forbidden-ただし、このケースと、ユーザーがこのアクションを実行する権限を単に欠いている他のケースを区別したいと思います。401 Unauthorized-良い考えではありません。認証関連の問題に使用しています。402 Payment Required-理にかなっていますが、非標準で予約済みのステータスコードの使用が心配です423 Lockedのようなあまり標準的ではないもの。将来的には他の何かに使用することはほとんどありません。
もう1つのオプションは、403などの非常に標準的なものを使用することですが、応答本文にエラーの詳細を示します。
（a）長期的には最も効果的に機能し、（b）RESTfulの原則をより適切に使用できると考えているアプローチを考えています。
403が唯一の妥当な応答だと思いますが、405メソッドは許可されていないか、409競合は許容できるかもしれませんが、次のように403ほど良いとは思いません。
サーバーはリクエストを理解しましたが、リクエストの実行を拒否しています。承認は役に立たず、リクエストは繰り返されるべきではありません。リクエストメソッドがHEAD=でなく、サーバーがリクエストが満たされていない理由を公開したい場合は、エンティティでの拒否の理由を説明する必要があります。
403エラーを返す場合、リソースが拒否された理由に関するいくつかの情報が含まれます-無効な権限は最も一般的なケースにすぎず、制限を超えてもそれほど違いはありません-制限を超えたため、権限がありません。
403は間違っていると思います。403はリソースにアクセスできず、アクセスする方法がまったくないためです。あなたの顧客にとって、明らかにアクセスする方法があります：支払い。
401は本当に間違っています。なぜなら、それを認証に使用しているだけでなく、それがそこにあるからです。
あなたがAPIを書いているので、誰かがAPIを使用するコードを書く必要があり、その人があなたのAPI仕様を読む必要があると思います。 429 "Too many requests"で行くかもしれません。これは通常、レート制限（クライアントが1日あたり100リクエストを実行できるなど）を目的としていますが、状況に適度に適用されます。 402（お支払いが必要です）でも構いません。 APIを使用するために人々が使用することを期待するツールによって異なります。 429には、巧妙なツールが1分あたり、1時間あたり、1日あたりのリクエストの送信数を減らし、成功しないというリスクがあります。
ちなみに https://tools.ietf.org/html/rfc6585 429エラーには、問題の性質を説明するhtmlメッセージも含まれているはずなので、ユーザーに実際に何が通知されている可能性が高いです問題は、応答でその情報を提供する場合です。
WebDAVはこれにHTTP 507 Insufficient Storageを使用し、それを区別するために、リクエスト本文にクォータ超過の追加エラーコードを含めます他の種類のストレージ制限から。