REST API からエラーを返す場合のベストプラクティスに関するガイダンスを探しています。現在、新しい API を開発中なので、どの方向にも進めます。現在のコンテンツ タイプは XML ですが、将来的には JSON をサポートする予定です。
現在、いくつかのエラーケースを追加しています。たとえば、クライアントが新しいリソースを追加しようとしたが、ストレージのクォータを超えている場合などです。すでに、HTTP ステータス コードを使用して特定のエラー ケースを処理しています (認証の場合は 401、承認の場合は 403、単純に不正なリクエスト URI の場合は 404)。ありがたい HTTP エラー コードを確認しましたが、400 ~ 417 の範囲のどれも、アプリケーション固有のエラーを報告するのに適切ではないようです。そのため、最初は、200 OK と特定の XML ペイロード (つまり、さらに料金を支払えば、必要なストレージが手に入ります!) でアプリケーション エラーを返そうと思いましたが、よく考えてみると、それは石鹸のようにきついようです (/恐ろしそうに肩をすくめる)。さらに、エラー応答を個別のケースに分割しているように感じます。一部は HTTP ステータス コード駆動で、その他はコンテンツ駆動です。
では、業界の推奨事項は何でしょうか? 優れたプラクティス (理由を説明してください!) と、クライアントの観点から、REST API のどのようなエラー処理がクライアント コードの作業を容易にするのでしょうか?
ベストアンサー1
API の正しい HTTP エラー コードを選択するための優れたリソース:http://www.codetinkerer.com/2015/12/04/choosing-an-http-status-code.html
記事からの抜粋: