はじめに
業務をしていてswagger uiを初めて使用したので
わからなかったのでアウトプットしようと思って記事を作成しました！
何をするものなの？
API仕様書をブラウザで見られる対話的なドキュメントに変換するツールのことを指す
ポイント
- その場でAPIを実際に試せるところ
具体的にいうと？
このAPIにはどんなエンドポイントがあって、どんなパラメータを受け取り、どんなレスポンスを返すかを書いたファイルを読み込ませると、次のような画面が出てくる。
- エンドポイント一覧（
GET /users,POST /usersなど） - 各エンドポイントのパラメータ・リクエスト形式・レスポンス形式の説明
- 「Try it out」ボタン → パラメータを入力して実際にリクエストを送り、結果を見られる
どの時に使うものなの？
複数の人がそのAPIを触る可能性があり、使い方の共有と動作確認を楽にしたい時に使用する！
使い方の共有と動作確認を楽にするって具体的には？
① API を作った人が「使い方の説明書」を渡したい時
APIを作っても、他の人（フロント担当、外部の開発者）はどんなURLに、何を送れば、何が返ってくるのかを知らないと使えない。
それを口頭やテキストで説明するのは大変なので、そこでSwagger UIを置いておけばここを見てで済む！説明書を省くというのが1番の大きな用途だと思う
② 動作確認・デバッグをサッとしたい時
「このエンドポイント、ちゃんと動くかな？」を確かめたい時、
本来なら curl コマンドを打ったり Postman を開いたりする。
Swagger UI なら画面上の「Try it out」でパラメータを入れて実行できるので、
ツールを立ち上げる必要がなく作りながら「動くか試す」場面で便利！！
③ フロントとバックの担当者が仕様をすり合わせる時
チーム開発で「レスポンスの形どうなってる？」「このパラメータ必須だっけ？」というやり取りは頻繁に起きることがある、しかしSwagger UI があれば、それを見れば全員が同じ認識を持てるので、認識ズレを防求ことができる
まとめ
つまり「API仕様書+動作確認ツール」が一体になったもの、というイメージですね！！
実務が1番力になることは間違い無いですが、やはり大事なのはわからないことを分からないままにしないこと、こういった基礎の基礎からやり直すことが大切かなと思いました。。
そして、フロント、バックエンド、インフラを全て見れることがとても大事かなと痛感させられました。なぜかと言うと、フロントだけのコードの実装はできても、バックエンドのデータの処理の流れ、インフラのどの環境にどうやって通信しているのかを自分が理解していないと
APIの繋ぎ込みに関しても動作環境がうまくいかなかったりそのアプリ自身についても理解が浅いまま話していて分からないことがわからないからです
なので、個人開発で一気通貫して実装をしてアプリ全体の把握、そしてインフラ環境の構築をして
どこでなんの問題が起きていることを切り分けして解決できることの大切さを学びました
個人開発をする等の目的だと個人開発をすることが手段に入れ替わるので
なんで、なんのために個人開発をするのかという抽象的な目的が必要かなと感じました、、
日々、勉強していこうと思いました🙇