ぼくのかんがえたさいきょうの API エラーレスポンスのフォーマット
エラーハンドリングについてじっくり考えてみたシリーズ Web サービスを開発するときのエラーハンドリングについて API から返ってきたエラーレスポンスのフォーマット（型）はどういうのが良いのかについて考えてみました。 デファクトスタンダードはどれ？ WebAPIでエラーをどう表現すべき？15のサービスを調査してみた - Qiita などで取り上げられているように、現状各社のエラーレスポンスのフォーマットはかなりばらばらです。 ちなみに JSON:API という仕様があり、API がこの仕様に則って作られている場合はエラーレスポンスのフォーマットが定義されているため、これに沿ったエラーレスポンスを作れば良さそうです。 しかしそうでない API の場合は、エラーレスポンスだけ JSON:API に沿うのは違う気がします。レスポンスのフォーマットとして参考にはなるかもしれませんが。 というわけ
Web サービスを開発するときのエラーハンドリングについて
一言にエラーといっても色々あるのでまとめてみました。 エラーの種類 エラーは、予期したエラーと予期せぬエラーの2種類に大別できます。 予期したエラー バリデーションエラー API から返ってくるレスポンスエラー クライアントエラーレスポンス（400系） サーバーエラーレスポンス（500系） 予期せぬエラー ネットワークエラーなどの通信エラー DB やサーバーがダウンしたなど バックエンドのコードのバグ フロントエンドのコードのバグ 大前提としてエラーが起こったら、ユーザーが次に行うべきアクションが分かるような何かを伝えることが最重要だと考えています。 まず予期したエラーが起こった場合について考えてみます。 バリデーションエラー フロントエンドのバリデーションエラーはユーザーの入力時にチェックし、即時でユーザーに教えてあげるのが UX 的に良いです。 フロントエンドでチェックしているから、バ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
