APIをコードから
切り離して試す。
PostmanとAPIDOG。

API連携を実装していると、 うまく動かないことがあります。

そのとき、 アプリケーション全体から呼び出していると、 どこで問題が起きているのか 分かりにくいことがあります。

呼び出し側のコードなのか。

Requestの内容なのか。

認証なのか。

API側なのか。

だったら、
APIだけ直接叩いてみる。

その確認でよく使っていたのが Postmanでした。

Postmanでは、 URL、HTTPメソッド、 Header、認証情報、Bodyを設定して APIを直接呼び出せます。

例えば、 POSTするAPIなら、 URLを入れて、 POSTを選んで、 Headerを設定する。

必要なら認証情報も入れる。

BodyにJSONを入れて送信する。

POST /users

Content-Type: application/json
Authorization: Bearer xxxxxxxx

{
    "name": "Taro",
    "age": 30
}

送ると、 Status Codeや Response Bodyが返ってきます。

実装側のコードを通さずに APIそのものを確認できる。

これだけでも、 切り分けがかなりしやすくなりました。

この差は、 切り分けではかなり使えました。

Postmanから同じAPIを叩く。

そこで正常に動く。

なら、 APIそのものより 呼び出し側のコードや設定を見る。

逆に、 Postmanから直接叩いても 同じエラーになる。

それなら、 API仕様や認証、 接続先、 相手側の処理も見る。

同じAPIを、
別の経路から試す。

これだけで、 問題の範囲をかなり狭められました。

Postmanでは動くのに、 コードからだと動かない。

そうなったら、 両方のRequestを見比べます。

• URLは同じか
• HTTPメソッドは同じか
• Headerは同じか
• 認証情報は同じか
• Bodyは同じか

一見同じに見えても、 Headerが一つ抜けていたり、 JSONの値が違っていたりします。

動く方が一つあるだけで、 比較対象ができます。

その状態は、 原因を追うときかなり楽でした。

APIテストでは、 Requestを作ることだけに 意識が向きがちでした。

でも、 返ってきたResponseの方に 原因が出ていることもあります。

HTTP/1.1 400 Bad Request

{
    "message": "userId is required"
}

Status Codeを見る。

Response Bodyを見る。

エラーメッセージを見る。

何を送ったかと、 何が返ってきたかを 一緒に見る。

それがAPIテストの基本になりました。

その後、 複数実行や負荷を見るようなテストで、 JMeterを使うことになりました。

ただ、 JMeter自体を 深く使い込んだわけではありません。

自分の中では、 「こういうテストをしたいから、 これ使ってみて」 と言われて触ったくらいです。

複数回実行する。

同時実行する。

実行結果を見る。

そういうことができるのは分かりました。

ただ、 当時はJMeter自体が初見だったので、 設定や画面の見方から確認する必要がありました。

JMeterを触ったあと、 APIテスト周りを自分でも調べました。

そこで見つけたのが APIDOGでした。

最初の印象は、

「これ、使いやすそうじゃん」

という感じでした。

実際に触ってみると、 APIをプロジェクト単位でまとめたり、 複数のAPIを並べて確認したりする用途で 扱いやすかったです。

複数実行したり、 処理時間を見るようなテストでも 使いました。

自分の中では、 普段のAPI単体確認ならPostman。

複数APIをまとめて扱ったり、 プロジェクト単位でテストするときはAPIDOG。

そんな使い分けになっていきました。

APIDOGを実際に触ってみて、 プロジェクトの中でも 使いやすそうだと感じました。

それで、 「これ便利じゃん」 となって、 今後も使おうという流れになりました。

最終的には、 APIまわりの確認で PostmanとAPIDOGを使う形になりました。

どちらか一つに統一するというより、 用途に合わせて使う。

Postmanは、 普段のAPI単体確認や Request / Responseの確認。

APIDOGは、 複数のAPIをまとめて扱ったり、 プロジェクト単位でテストするとき。

必要になったものを調べて、 使いやすかったものを 現場に持ち込んでいく。

こういう流れは、 APIテスト以外でもよくありました。

APIを直接試せるようになると、 相手側に確認するときも 話がしやすくなります。

「動きません」 だけではなく、

このURLに、 このMethodで送った。

Headerはこれ。

Bodyはこれ。

Status Codeはこれ。

Responseはこれ。

何を試して、
何が返ったかを共有できる。

外部連携では 相手側にしか見えない情報もあるので、 ここまで整理して渡せるだけでも 確認がかなり進めやすくなりました。