RequestとResponse、
どこを見ればいい？

API連携でエラーになると、 最初は呼び出しているコードを ずっと追っていました。

変数は合っているか。

JSONは正しいか。

メソッドの呼び方がおかしくないか。

もちろん、 そこに原因があることもあります。

でも外部連携では、 自分のコードだけを見ても 判断できないことがありました。

何が悪いかを探す前に、
どこまで正しいかを見る。

この見方に変えてから、 RequestとResponseを 一つずつ確認するようになりました。

Requestを見るときは、 「コード上ではこうなっている」 だけではなく、 実際に何を送ろうとしているのかを確認します。

• 送信先URL
• HTTPメソッド
• Header
• 認証情報
• Body

例えば、 JSONをPOSTするなら こんな形になります。

POST /users

Content-Type: application/json
Authorization: Bearer xxxxxxxx

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

URLが違っていないか。

POSTのつもりが GETになっていないか。

Headerが抜けていないか。

認証情報が正しいか。

BodyのJSONが想定どおりか。

Requestだけでも、 見る場所はいくつもあります。

コード上では 正しい値を設定しているつもりでも、 最終的に組み立てられたRequestが 想定と違うことがあります。

JSONを作る途中で 値が変わっている。

必要な項目が入っていない。

型が違う。

Headerの値が想定と違う。

だから、 途中の変数だけを見るのではなく、 最後に何を送るのか を見ることも大事でした。

{
    "userId": 100,
    "active": true
}

期待している形と、 実際に送っている形を比べる。

ここでズレていれば、 相手側を見る前に 呼び出し側を直せます。

Requestを送ったあと、 Responseが返ってきたなら、 そこからもかなり情報を拾えます。

Responseでは、 主にこの辺を見ます。

• Status Code
• Response Header
• Response Body
• エラーメッセージ

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
    "message": "userId is required"
}

この場合、 ただ 「400だった」 だけではありません。

Bodyを見ると、 userId が必要だと 返してくれています。

エラーの原因が Response Bodyにそのまま出ていることもあるので、 Status Codeだけ見て終わらないようにしていました。

Status Codeを見ると、 次にどちら側を確認するかの 目安になります。

• 200系：処理自体は成功しているか
• 400系：Request、認証、指定内容を見る
• 500系：サーバー側の処理や環境も見る

例えば 401 なら、 認証情報を見る。

403 なら、 権限も確認する。

404 なら、 URLや対象リソースを見る。

そして、 500 が返ってきたとき。

ここは、 実際に何度か 「そっちか」 となったところでした。

URLを確認する。

Headerを見る。

認証も確認する。

JSONも見直す。

それでもおかしい。

Responseを見ると 500。

「サーバー側で、
何か起きてるのか？」

そこで、 自分のコードだけを見るのをやめて 相手側にも確認する。

すると、 意外とこういうこともありました。

「ごめん、テストで一回止めてた」

「スケジュール入れてなかったっけ？」

テストサーバーにアクセスが集中して、 落ちていた。

再起動しないと戻らない。

ここまで来ると、
もう自分のコードだけ見ても分からない。

もちろん、 500 だから 必ず相手側だけが悪い、 という意味ではありません。

こちらから送ったデータをきっかけに、 相手側の処理で 例外が発生していることもあります。

ただ、 Status Codeを見て 「そろそろ相手側も確認した方がいい」 と見る方向を変えることは大事でした。

APIをコードだけで見ていると、 どうしても 自分のアプリケーションの中だけで 原因を探しがちでした。

でも外部連携は、 自分のシステムだけで 完結していません。

Requestを送る先には、 相手側のAPIがあります。

その先には、 相手側のアプリケーションがあります。

さらに、 テストサーバーや ジョブ、 スケジュール、 権限、 運用があります。

コードの向こう側に、
別のシステムと人がいる。

だから、 自分のRequestが正しく見えるなら 相手側に聞くことも必要になります。

「今そちら動いてます？」

「この時間、 テスト環境止めてません？」

「こちらから500が返ってきてます」

こういう確認で 一気に原因が分かることもありました。

技術的に全部自分で調べ切ることだけが、 外部連携の切り分けではありません。

相手側にしか見えない情報があるなら、 そこは確認する。

その判断も、 実際の開発ではかなり重要でした。

呼び出し側のコードからだと うまく動かないとき、 APIを直接呼び出して 同じ条件を試すこともありました。

直接呼び出したときは正常に動く。

それなら、 APIそのものより 呼び出し側の実装や設定を見る。

逆に、 直接呼び出しても 同じエラーになる。

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

同じAPIを、
別の経路から試してみる。

これだけでも、 問題がどちら側にありそうか かなり分けやすくなります。

自分はこの確認に、 PostmanなどのAPIテストツールを使っていました。

ツール自体の使い方や テストの進め方は、 次の記事でまとめます。

Responseだけでは 原因が分からないこともあります。

そういうときは、 呼び出し側やサーバー側のログも見ます。

Requestを送る直前の値。

受け取ったResponse。

例外が発生した場所。

相手側でRequestを受け取った記録。

画面上では 「エラーになった」 だけでも、 ログを見ると どこまで処理されたのかが分かることがあります。

Request → Response → Log

一つだけを見るより、 それぞれをつなげて見る方が 原因を追いやすかったです。

相手側のログが必要なら、 そこは相手に確認する。

外部連携では、 自分から見える範囲だけで 全部判断しようとしないことも大事でした。

API連携で何か起きたとき、 最初から全部を見ると 範囲が広くなります。

自分の中では、 だいたいこんなところから 順番に確認するようになりました。

1. 送信先URLとHTTPメソッドを見る
2. Headerと認証情報を見る
3. 実際に送るBodyを見る
4. ResponseのStatus Codeを見る
5. Response Bodyを見る
6. 必要ならAPIを直接呼び出して比較する
7. ログでどこまで処理されたかを見る
8. 自分側で判断できなければ相手側にも確認する

必ずこの順番というわけではありません。

ただ、 「とりあえず自分のコード全部を見る」 より、 正常な場所を一つずつ増やしていく方が 自分には分かりやすかったです。