REST APIのエラー構造のベストプラクティスは何ですか？私はそれを記述するためにHTTPでコードを使うべきであることを知っていますが（REST API error return good practices）、構造は常に便利です。エラーのタイプとエラーの理由（raise CanNotCreate('Because of this')）のようなものを常に使用していました。REST APIのエラー構造を定義する
エラーメッセージの構造を定義するベストプラクティスは何ですか？優れたエラー処理を備えた特定のAPIの例を挙げることはできますか？
通常、応答ステータスの理由フレーズ（たとえば、より一般的な409 Conflictの代わりに409 Cannot Create）に「タイプ」が表示されます。これは、HTML、XMLなどのメディアタイプを解析せずにコンピュータで解析できるためです。 JSON。通常、Reason-Phraseは、マシンクライアントが適切な処理を行うのに十分です。特に、あるリソースがわずかに異なる理由で同じコードを返す場合があります。
次に、レスポンス本文には、他の場所で使用する同じメディアタイプのプログラマとエンドユーザの両方の情報を追加します。リクエストが成功し、例えば200 OKをJSONに戻した場合は、JSONをエラー応答とともに返します。それ以外の場合は、あなたのAPIに対して開発している人々を本当に不満にします。
最後に、メディアタイプで許可されている場合は、クライアントが問題の解決に役立つように、可能な限りハイパーリンクを含めます。