TL;DR バージョン: 主に、クライアントが対応できるコードと情報を使用して例外応答を設計します。標準の HTTP ステータス コードを可能な限り活用します。クライアント アプリの動作をガイドするために、HTTP 仕様にあるものを超えて提供するものを文書化します。次に、可能であれば、クライアント開発者が開発とトラブルシューティングに使用できる情報を提供します。
HTTP ベースの API のエラー応答を設計する際に、エラー応答に基づいてクライアント側でどのような期待と対応する動作がトリガーされるかを自問します。クライアントが HTTP ステータス コード 500 を受信した場合、サーバーで何らかの「誤動作」が発生したため、リクエストを適切に処理できなかったと見なすことができます。ステータス コード 500のHTTP 仕様によると、これは別のコードを適切に割り当てることができない場合の包括的なステータス コードの一種です。サーバーがちょうど「ブーム」になったことを知っていることを除けば、クライアントにとってはあまり役に立ちません。ただし、HTTP ステータス コード 503 Service Unavailable があり、Retry-After
HTTP ヘッダーを介して、停止が続く可能性がある情報をクライアントに提供します。
コメントの特定の例では、データベース例外があったことをクライアントに伝えることはあまり役に立ちません。クライアントがそれに対してできることはおそらくないからです。運用担当者や開発者が使用できるように、サーバー側の例外に関する詳細情報をログに記録し、HTTP ステータス コードでクライアントに問題を通知します。
唯一の例外は、リクエストの解析に失敗したときに、予期しない要素や不足している要素 (など) に関する詳細情報を提供することです。これは、400 Bad Request の HTTP ステータス コードを含む応答の一部として送信します。クライアント アプリはおそらくその情報を使って何もできませんが、クライアント開発者はそれを高く評価します。