成功にも種類がある

ネットワーク講座のステータスコードを、今度は返す側として選びます。 ありがちな失敗は「何でも200で返し、本文の中にerror: trueを入れる」設計です。これをやると、使う側は本文を全部パースするまで成否が分からず、監視ツールもエラーを検知できません。

エラーレスポンスの形を決める

エラー時のJSONの形をAPI全体で統一します。 code: プログラムが分岐に使う機械可読な識別子 message: 人間（開発者・ユーザー）向けの説明 details: フォームの項目別エラーなど、具体的な内訳

良いエラーは開発者体験そのもの

「Bad Request」とだけ返すAPIと、「titleが必須です」と返すAPI。使う側の調査時間は10倍違います。 何が悪かったのか（field単位で） どうすれば直るのか（形式・制約の情報） ただし内部情報は漏らさない: スタックトレースやSQLをそのまま返すのはセキュリティ事故（攻撃者へのヒント提供）

• 適切なステータスコードの選び方
• エラーレスポンスの設計
• 「使う側の身になる」エラーメッセージ