正しく使えば効果的!Web APIのステータスコードは何を返すのが正しい?
こんにちは。突然ですが、皆さんはWeb APIを作成するとき、レスポンスのステータスコードを意識していますか?200 OKとか500 Errorとかのあれです。そんなの常識じゃね?という方から、なにそれおいしいの?という方までいらっしゃると思います。かくいう私も昔は後者よりの方でした。しかし、ステータスコードを意識すると、APIを使う側になった時にすごく得をします。それでは一緒に見ていきましょう。
ステータスコードは200と500だけではない
成功したら200、エラーは500を返す印象があるかもしれません。しかし、RFCではもう少し細かく定義されています。以下に私がよく使うものを挙げてみます。
200 OK | 処理が成功した |
201 CREATED | データの登録が完了した |
202 ACCEPTED | データの処理を受け付けた |
204 NO CONTENT | 返すコンテンツはありません。 更新やデータ削除処理のレスポンスとして使用されます。 |
422 Unprocessable Entity | リクエストは適性ですが、意味が違っているため処理できません。 処理しようとした値が不正な場合に返します。 入力チェックに引っかかった場合に使います。 |
500 Internal Server Error | アプリの例外エラーなど。 |
MDNライブラリにわかりやすい説明がありますので興味のある方は以下のリンクからどうぞ。勉強になりますよ!
https://developer.mozilla.org/ja/docs/Web/HTTP/Status
何が嬉しいか
ステータスコードを分けることでどのような利点があるのでしょうか。私は以下のような利点があると考えています。
- 操作の結果をかえすので、どのような操作をするAPIなのかがわかりやすい。
- 障害の原因切り分け
使う側にとって、どのような処理が実行されたのかが、ひと目でわかるので開発がはかどるように感じます。障害時にも単純に500を返されると、ログを見ないと詳細がわからなかったりします。ステータスコードである程度推測ができるとかなり便利なのではないかと思います。
ステータスコードは数がそこまで多くない(約30)ので、全て頭の中に入れてしまったほうが便利に使えるかもしれません。ユーザーに優しいAPIを目指していきましょう。
ディスカッション
コメント一覧
まだ、コメントがありません