今回は、API設計にも必要となるステータスコード（200番台・400番台）についてまとめたので共有していきます。
どもどもコンバンハ！Amazonのブラックフライデーが来てましたね。最近友達たちが僕の家に電子レンジがないことに関して議論をしていたので、ついにオーブンレンジを購入しましたね。一人暮らしを始めて、3年弱初めて電子レンジを購入しましたね。電子レンジのある生活というコラムを書いてしまおうか、悩む程度には舞い上がっていますね。冗談です！
さて先ほども書きましたが、API設計に必要となるステータスコードのお話です。僕がここ数年興味がある分野はフロントエンドなのですが、今回のお話はそれと仲良しのバックエンドのお話になります。自主開発に必要となるアイテムの話をこれから少しづつまとめてシリーズ化していきますのでよろしくお願いします。今回参考にした記事は以下にまとめておきます。
ステータスコード
今回お話しするステータスコードの図になっています。200番台と400番台ですが、200番はAPIに対して成功した場合に返されて、400番台は失敗したときに返されます。各項目について次章で説明していきますね。最近、資料作成の仕事のめどが立ちまして、残ったのはちょっとの知識とFigmaの技能ですね。Figmaに関していえば、ブログに役立っているのでよいですな。こういった記事の場合文章で書くよりも図を作った方が良いのではないかと悩んでしまいますね。
200番台
正直、調べるまで「全部一緒やろ」とか考えてました。明確な使い分けが存在していたんですね。POSTで送信した場合は、送ったリクエストをそのまま返すのが良いという話を先輩社員から聞いたのですが、まだ知識的にも浅いのでAPI強つよな先輩社員を捕まえて勉強する必要がありますね。なのでざっくりとした理解でお話しします。201はPOSTでデータを作るときに、204はデータをこねくり回した後で成功したときにという風な理解でよいと思います。GETは200でデータと共に…
400番台
さて～あまりこの番数は見たくないですよね。フロントエンドとなじみが深いのは「400・401」ですね。400はリクエストボディの中身が規定通りに書いていないときに帰ってきます。これは、仕様書と格闘して乗り越えましょう。401は認証キーが含まれていないとかセッション切れとか原因はいろいろありますが、仕様書でぶん殴られる前に仕様書と仲良くしましょう。403はあまり見たことないですが、ローカルからアクセスしか許されていないAPIなどではあるようですね。
404・405も仕様書で殴られるので仕様書はしっかり読みましょう。というか、APIのエラーは世の中の人が大体引っかかっているので、エラーメッセージと共にネットの海と仕様書の海に泳ぎに行きましょう。
終わりに
さて今回はこれからの自主開発に必要となるアイテムのお話だったので軽めの記事になっています。これからも必要なアイテムのお話を進めていきますので、よろしくお願いします( *´艸｀)
さて～最後に最近の一押し記事を共有しておきますね。こちらも読んでみてください。この一押し記事が更新される日が来るのが楽しみですね。
ではまた～
