[解決済み] REST APIのエラーリターンに関するグッドプラクティス【終了しました

質問

REST APIからエラーを返すときのグッドプラクティスについてガイダンスを探しています。私は新しいAPIに取り組んでいるので、今すぐどのような方向にも持っていくことができます。私のコンテンツタイプは、現時点ではXMLですが、将来的にはJSONをサポートする予定です。

例えば、クライアントが新しいリソースを追加しようとしたが、ストレージのクォータを越えてしまった場合などです。私はすでにHTTPステータスコードで特定のエラーケースを処理しています（401は認証、403は承認、404は単純に悪いリクエストURI）。HTTPのエラーコードに目を通しましたが、400から417のどれもがアプリケーション固有のエラーを報告するのには適していないようです。だから最初は、アプリケーションのエラーを200 OKと特定のXMLペイロード（つまり、もっと払ってくれれば、必要なストレージが手に入る！）で返そうかと思ったのだが、考えるのをやめたら、それは石鹸みたいだ（/shrug in horror）。それに、あるものはhttpステータスコード駆動で、他のものはコンテンツ駆動なので、エラーレスポンスを異なるケースに分割しているような気がするのです。

では、業界の推奨事項は何でしょうか？グッドプラクティス（その理由を説明してください！）、またクライアントの視点から、REST APIでのどのようなエラー処理がクライアントコードの生活を楽にするのでしょうか？

どのように解決するのですか？

そこで最初は、アプリケーションのエラーを200 OKと特定のXMLペイロード（つまり、もっとお金を払えば、必要なストレージが手に入る！）で返そうかと思いましたが、考えるのをやめて、石鹸のようです（/恐ろしさに肩をすくめる）。

私なら、本当に何も問題がない限り、200を返しません。以下より RFC2616 200は「リクエストに成功しました」という意味です。

クライアントのストレージのクォータが（何らかの理由で）超過している場合は、403（Forbidden）を返すことにしています。

サーバーは要求を理解しましたが、要求を満たすことを拒否しています。認証は役に立ちませんし、リクエストは繰り返してはいけません(SHOULD NOT)。リクエストメソッドがHEADでなく、サーバーがリクエストが遂行されなかった 理由を公開することを望む場合、エンティティに拒否の理由を記述するべきで ある[SHOULD]。サーバーがこの情報をクライアントに提供することを望まない場合、代わりに ステータスコード404(Not Found)を使用することができる。

これはクライアントに、リクエストはOKだったが失敗したことを伝えるものです（200ではできないことです）。また、レスポンスボディで問題（とその解決策）を説明する機会にもなります。

その他、具体的にどのようなエラー状況を想定していましたか？