API デバッグ ツール: エンドポイントが自分にあったときに開く 6 つのタブ

Laravel プロジェクトの 1 つでライセンスをアクティブにするエンドポイントが、渡されたすべてのトークンを拒否し始めました。 一部のトークンではありません。 同じサーバーが 90 秒前に発行したものを含め、すべてのトークン。 ログは言った token expired。 トークンは期限切れではありません。 箱の時計がずれていると確信して、土曜日のほとんどを過ごしました。

ありませんでした。 バグは 1 行でした。

if (payload.exp < Date.now()) throw new Error('token expired')

exp JWT では、 秒 時代以来、RFC 7519 §4.1.4 はそれについて明確です。 Date.now() JavaScript が返す ミリ秒。 そこで私は、10 桁の数字と 13 桁の数字を比較していましたが、10 桁の数字は常に小さくなっています。 宇宙のすべてのトークンは、永久に期限切れになりました。 修正は Date.now() / 1000。 実際には一度もなかったので、診断に 8 時間かかりました 見えた トークンでは、私は自分のコードを読み直し続けました。これは、メガネを着用しながらメガネを検索するのと同等のデバッグです。

最終的にループを破ったのは、トークンをデコーダに貼り付けて読み取ることでした。 exp: 1748952000、それを日付に変換し、2 週間後にタイムスタンプを表示します。 トークンは大丈夫でした。 私の比較は間違っていました。 データを 30 秒間見るのは、8 時間のコードの比較に勝るものでした。

That's what this guide is about. 巧妙なデバッグ哲学ではない - 特定、退屈、魅力のないブラウザツール私は、" APIデバッグ、" と呼ばれるタブグループ内に保持しているそれぞれの実際の目的、およびそれらがキャッチする障害モード、ここですべてがクライアント側で実行されます Toolz.dev、これは、あなたが貼り付けようとしているものがプロダクション ベアラー トークンである場合に、より重要です。

tl;dr: API の動作が不十分な場合は、コードの読み取りを停止して、ペイロードの読み取りを開始します。 で応答をフォーマットします。 JSON フォーマッタ。 でトークンをクラック JWT デコーダ、一般的な base64 ツールではありません。 曲がる exp、 iat、そして X-RateLimit-Reset と実際の日付に タイムスタンプ コンバーター。 壊れた応答と、実際の応答を比較してください。 テキスト差 または、より良い、 json 差分。 を使用してクエリ文字列を解読する URLエンコーダ。 それはすべてブラウザで実行されます - トークンは決してワイヤーを越えません。

API デバッグは、コードのデバッグよりもはるかに悪く感じるのはなぜですか?

ステップを踏むことができないからです。 ローカル バグには、スタック トレース、デバッガー、ブレークポイントがあります。 API バグには文字列があります。 他の誰かのサーバーがその文字列を作成しました。ルールによると、半分しか分かっていません。あなたの仕事は、それから逆方向に作業することです。

これで通常のスキルが反転します。 ボトルネックはロジックではなく、 可読性。 ここ数年で追跡したほぼすべての API バグは、データを読み取り可能にするまでは見えませんでした。

• 4,000 文字の JSON 応答を縮小して、次のようになっています。 "data": null 深さ6で埋葬。
• エラー メッセージにデコードした Base64 ペイロード。API は、ステータス コードを入れるにはあまりにも礼儀正しいものでした。
• ボディに新しい行があったため、署名の検証に失敗した Webhook の HTTP クライアントが役に立ちました。
• ドキュメントが秒と言ったときにミリ秒単位のタイムスタンプ。 (2回。 異なる会社。）

これらはどれも難しい問題ではありませんでした。 全員でした 読めない 問題。 以下のツールは、データを十分に速く読みやすくするためのものです。そうでなければ、目が滑り落ちるものに気付くでしょう。

どの症状のツール?

これは、5 年前に誰かが私に渡しておけばよかったと思っている表です。 症状が左側に表示され、まず右に移動します。

以下はすべて、そのテーブルの長いバージョンです。

API レスポンスを 10 秒で読み取れるようにするにはどうすればよいですか?

に貼り付けます JSON フォーマッタ。それと#39;テクニック全体、そしてI'私は口先だけではありませんが、私が持っている唯一の最高レバレッジのデバッグ習慣は拒否することです 理由 フォーマットしていないペイロード。

これは、請求プロバイダーから得た応答の形です。これは、まさにその通りです。

{"subscriptions":[{"id":"sub_7f3d8a2b","status":"active","plan":{"id":"pro_annual","interval":"year","amount":9900},"current_period_end":1748952000,"cancel_at_period_end":false}],"has_more":false}

Formatted, it' s a different object entirely - not to the parser, but to me:

{
  "subscriptions": [
    {
      "id": "sub_7f3d8a2b",
      "status": "active",
      "plan": {
        "id": "pro_annual",
        "interval": "year",
        "amount": 9900
      },
      "current_period_end": 1748952000,
      "cancel_at_period_end": false
    }
  ],
  "has_more": false
}

今、私はそれを見ることができます amount です 9900 そして、ない 99.00ー it' s in cents, これは、支払いにおける唯一の最も一般的な統合バグです - そしてそれ current_period_end は 10 桁の整数です。つまり、秒を意味します。つまり、渡さないことを意味します。 new Date() 直接。

検証はあなたの目には見えないものを捕まえます

フォーマットも検証します。 解析の失敗は情報です。 実際のペイロードで実際に表示されるエラー:

• トレーリング・コンマ。 JavaScript では合法、JSON では違法 (per) RFC 8259).手編集の什器が、いっぱい.
• 一重引用符。 JSON には二重引用符が必要です。 str(dict) どんなに見えても、出力は JSON ではありません。
• 引用されていないキー。 同じ話 - それと#39; S は JSON ではなく JavaScript オブジェクトのリテラルです。
• NaN / Infinity。 一部のシリアライザーはそれらを発行します。 JSON には、そのようなリテラルはありません。
• ボム。 前にある UTF-8 バイトオーダーマーク { 厳密なパーサーは、画面上で完璧に見えるドキュメントを拒否します。

JSON が有効な場合でも、 形 間違っています、それは' s は別のツールです - 以下の異なるセクションを参照してください。

トークンを base64 でデコードするだけでなく、JWT デコーダを使用するのはなぜですか?

JWT を手でベース 64 デコードできます。 何年もやった。 それは悪い習慣です。その理由はここにあります。

JWT (RFC 7519) は、ドットで区切られた 3 つのチャンク (ヘッダー、ペイロード、シグネチャ) です。 各チャンクは base64url、標準ではない Base64 - RFC 4648 §5、URL を交換する安全なアルファベット +→- あんど /→_ そして通常はドロップします = パディング。 それを厳密な標準ベース64デコーダに送り、エラーか、ガベージバイトを黙って表示します。 つまり、hand メソッドとは、ドットで分割し、再パディングしてアルファベットを毎回交換し、その後に生の JSON を目玉にすることを意味します。

ザ・ JWT デコーダ それをすべて1 つのペーストで行い - 実際に時間を節約する部分 - クレームをクレームとして提示します 私がチェックするのは、順番に:

• exp (期限切れ) そして iat (で発行) - 両方 数字の日付、つまり 秒 1970-01-01 UTC 以来。 これが私の土曜日を食べた分野です。
• aud (聴衆) - ステージング API 用に作成されたトークンは構造的に完璧ですが、prod によって拒否されます。
• iss (発行者) - ID プロバイダーの移行後、この分野は静かに変化しました。
• alg ヘッダーに - と書かれている場合 none、デバッグの問題ではなく、セキュリティの問題があります。

誰もが見られる正規の例を見てみましょう。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

ヘッダー: {"alg":"HS256","typ":"JWT"}。 ペイロード: {"sub":"1234567890","name":"John Doe","iat":1516239022}。 あんど iat あるよ 2018-01-18T01:30:22Zこれは、次のセクションの全点であるタイムスタンプ コンバーターを介して実行することによってのみわかります。

デコーダがしないこと

デコードは検証していません。 誰でも JWT をデコードできます。ペイロードは暗号化されず、エンコードされます。 デコーダは、トークンを教えてくれる 主張、その主張が真実であるかどうかは決してありません。 署名の検証は、あなたの秘密を使ってサーバー上で行われます。ブラウザー ツールは、その秘密を渡してはなりません。 フォーム送信を扱う方法で、デコードされた JWT を扱います。見知らぬ人からのアサーションとして扱います。

タイムスタンプを間違えるのを止めるにはどうすればよいですか?

数字の数を読むことを学びます。 これは、フィールド全体で最も安価なデバッグ スキルであり、習得するのに 1 分かかります。

10 桁は秒を意味します。 13 はミリ秒を意味します。JavaScript は Date コンストラクターはミリ秒を望んでいます; Unix、Python's time.time()、行く Unix()、php's time()、そしてほとんどの API' exp フィールドは数秒で話します。 その不一致の下流のすべてがカオスです。

そして混乱は一方向では大音量で、他方では静かです。 フィード 秒 ミリ秒のパーサーにすると 1970 が得られます - 1分で修正できるほど明らかなバグです フィードします ミリ秒 に 秒 パーサーで年を取得します 56122。 私は確認しました： 1708876200000、秒として解釈し、年に17 2 月に着陸 56122. That& #39; s 静かに出荷する方向, 何かがスローするため - サブスクリプションは単に期限切れになることはありませんし、誰も四半期のために気づくことはありません。

ザ・ タイムスタンプ コンバーター これについて議論するのではなく、1 つのペーストで解決できるように存在します。 貼って 1748952000、日付を読み、先に進みます。 を貼り付けます X-RateLimit-Reset API が不満を言っているヘッダーで、4 時間ではなく 4 分待つ必要があることがわかります。 タイムスタンプがナイーブの場合 (いいえ Z、オフセットなし) であり、別の地域でそれが何を意味するのかを推論する必要があります。 タイムゾーン コンバーター フォローアップです。

知っておく価値のあるタイムスタンプ トラップがさらに 2 つあります

2038 年の問題は現実的で時代遅れです。 符号付きの 32 ビット秒のカウンターがオーバーフローします。 2147483647、つまり 2038-01-19T03:14:07Z.任意のシステムはまだ署名32 ビットintに時間を格納 - そして、誰もが認めたいよりも埋め込まれたとレガシーデータベースの列にそれらの多くがあります - その後、休憩。 you& #39; reは、今日、長寿命の有効期限を設定し、すでにこれをヒットすることができます。

単純なタイムスタンプは、省略による嘘です。 2026-02-25T14:30:00 トレーリングなし Z いいや +05:30 瞬間ではなく、不特定の場所にいる瞬間です。 単純なタイムスタンプを返す API を、ファイルが提出されるのを待つバグ レポートとして扱います。 RFC 3339 を優先する (2026-02-25T14:30:00Z)、これは、Web が実際に使用する ISO 8601 の厳密で明確なプロファイルです。

「昨日うまくいった」ときはどうすればいいですか？

それを差します。 Don't 理論化 - それを差します.

作業環境からの応答 (または、ログから最後の良いものを掘り下げる) と壊れた環境からの応答をキャプチャし、それらを並べて配置します。 10 分の 9 の場合、ちょうど 1 つの違いがあり、5 秒以内にあなたを見つめています。

JSON の場合、 json 差分 テキストの差分の前。 両面を解析して比較します 構造、これは、再順序付けされたキーと異なるインデントdon& #39; t変更として表示することを意味します - 唯一の実際のものは、します。 2 つのJSON文書のテキスト差分は、別のキー順序でシリアル化されたサーバーがクリスマスツリーのように点灯し、何も教えてくれません。

Isn& #39;t JSON - ヘッダー、未加工ボディ、構成ファイル、 curl 出力 - を使用します テキスト差。 その専門は、目が物理的にキャッチできない変化のクラスです。4 つのスペースになったタブ、Windows マシンからこっそりと終わる CRLF の行、例をコピーしたときにドキュメント サイトがストレートのドキュメント サイトに置き換えられたカーリー クォートです。 全文を書いた 目玉の比較が失敗する理由、サポートのエスカレーションが 1 回かかったからです。

クエリ パラメータが壊れたままになるのはなぜですか?

URL エンコーディングには 3 つまたは 4 つの微妙に異なるフレーバーがあり、すべてのスタックは異なるフレーバーを選択します。

古典は、どれだけ頻繁に私を噛んだかという大まかな順序で:

• + 対 %20。 クエリ文字列で、 + 歴史的には、スペース（ application/x-www-form-urlencoded 慣習）。 パス セグメントでは、 + 文字通りプラスを意味します。 つまり、base64 の署名には +、エンコードされていないクエリ文字列にドロップされ、スペースが含まれ、署名チェックは失敗します。 価値があるので、これは本当に厄介なものです 見ている ログにあります。
• ダブルエンコーディング。 %2F なる %252F スタックの 2 つのレイヤーは、どちらもそれをエンコードしたことがあります。 症状は、プロキシを通過するたびにパーセント記号を取得するパラメーターです。
• 生の & 値の内側。 パラメータを 2 つに分割します。 今 name=Ben & Jerry です name=Ben さらに、ミステリー パラムと呼ばれる Jerry。

URL を URLエンコーダ そしてそれをデコードします。 一度デコードしてもパーセント エスケープが残されている場合は、ダブル エンコーディングが見つかりました。 それが全体の診断です。

検証できない Webhook をデバッグするにはどうすればよいですか?

これは、「HTTP を理解しています」と「電話中だった」と分けているものです。

ほぼすべての Webhook プロバイダーが HMAC でペイロードに署名し、結果をヘッダーにします。 あなたの仕事は、同じ HMAC を計算して比較することです。 一致しない場合、署名が問題になることはほとんどありません。 バイトが問題です。 あなたは彼らがハッシュしたものをハッシュ化していません。

通常の容疑者:

1. 解析され、再シリアル化されたボディをハッシュ化しました。 フレームワークが JSON をオブジェクトに解析しました。 JSON.stringify() その上で、キーの順序または空白が 1 文字ずつ異なります。 ハッシュする必要があります 生 要求本文、受信したバイト数。 Express では、生のバッファーを前にキャプチャすることを意味します express.json() それに着きます; laravel では、それは意味します $request->getContent()、ない $request->all()。
2. 最後の改行。 一部のクライアントは 1 つを追加します。 プロバイダーはそうではありませんでした。
3. 生のバイトではなく、16 進数でエンコードされた文字列をハッシュ化しています、または base64 と Hex を比較します。
4. チャーセット。 本体にはマルチバイト文字があり、途中でトランスコードされたものがあります。

ザ・ ハッシュジェネレーター これを分離する方法です: 正確な本文文字列を取り、ハッシュして、自分のコードと比較して、それを何と比較しますか 考えた 同じ体でした。 この 2 つのハッシュが異なる場合、私のコードは、表示されていると思うバイト数が表示されず、問題はまったく暗号化されていませんでした。 (また、知っておく価値がある: プロバイダーが引き続き MD5 または SHA-1 署名を提供する場合、それはプラットフォームの時代に関するシグナルです。 SHA-256 は現在床です。)

デバッグタブグループには、他に何がありますか?

サポートキャスト - それほど魅力的ではありませんが、それでもその場所を獲得します:

• uuid ジェネレーターー掃除のため X-Request-ID テスト コールごとに、後で 3 つのサービスに合わせてそれを再認識できます。 UUID がスペックを更新したことは知っておく価値があります。 RFC 9562 (2024) 廃止されました RFC 4122 そして標準化 uuidv7は、時間順であるため、ランダムな v4 よりもデータベースの b ツリー インデックスに非常に適しています。 今日、新しいテーブルの ID スキームを選択している場合は、それが読み上げられます。 あります UUID バージョンのより長い内訳 あなたが望むなら。
• Base64 コンバーターー ため Authorization: Basic ヘッダー (RFC 7617: IT'S'S'S base64(user:password)、そしてはい、that& #39; sエンコーディング、セキュリティではありません - TLSはそれを保護するものです)、そしてインラインバイナリBLOBのために、いくつかのAPIはJSONフィールドに詰め込みます。 Base64 はあなたに約33% のサイズのオーバーヘッドを犠牲にします、それがなぜ" 予想外の大きさ" ペイロードはしばしばその中にファイルを持っているだけです 完全な base64 ガイド 人々をつまずかせる Base64URL の区別について説明します。
• YAML バリデーターなぜなら、昨年の私のAPI障害は半分' t API障害だったからです。 CIコンフィグの2 スペースのインデントエラーであり、エンドポイントはまったくデプロイされませんでした。 (YAMLは壊れたビルドよりも厄介な障害モードを持っていますが、: 有効なYAMLはあなたがやったことを意味します' 意図しませんでした)と書き上げました なんでや version: 1.10 1.1になる 展開が必要になった後。）
• 正規表現テスター- 現時点では、パターン you' を使用して、900 行のログからリクエスト ID を取得する必要があります。自信がありません。
• CSVビューア- 誰かが本番環境にインポートする前に、出力を健全性にチェックする必要があるエクスポート エンドポイントの場合。

これらがブラウザで実行されることは、実際に重要ですか?

そうです、サイトを構築していなくても、私はこれを言います。

デバッグツールに何を貼り付けるか考えてみてください。 A JWT - これは、 ライブ資格情報 期限切れになるまで。 顧客データである本番 API の応答: 名前、電子メール、サブスクリプションの状態。 支払い記録が含まれている可能性のある Webhook 本文。 あ curl でコマンド Authorization ヘッダーはまだあります。

ここで、定義上、サーバー側のツールがそのすべてを受信すると考えてみましょう。悪意のあるものではありません。アーキテクチャ上だけです。ペーストは HTTP リクエストに入り、誰かにヒットします's バックエンド、そして偶然実行されたログにランディングされます。細心の注意を払って誠実なオペレーターであっても、保持するつもりはなかったアクセス ログにベアラー トークンが追加されることになります。

ツールz.dev上のツールは、あなたのタブでJavaScriptで作業を行います。 nothing is uploaded, because there's nowhere to upload it to - the parsing, the decoding, the hashing all happen on your machine.あなたはdon' どちらかの私の言葉を取る必要はありません: devToolsを開き、ネットワークタブに行き、トークンを貼り付け、そして決して来ない要求を見てください。 that' s a thirty-second audit, and you should run it on どれでも 秘密を貼り付けるツール、私のものも含めて。 書き上げた クライアント側のツールを正しく検証する方法 まさにこの理由で。

あなたの組織がEUの個人データを扱う場合、これはisn& #39; 衛生だけではない - サードパーティのサーバーに顧客の記録を貼り付けることは、すべてのGDPRの事務処理が暗示する処理活動であり、クライアント側のツールは、プロセッサになることはまったくないことで、質問を回避します。

実際に固執するワークフロー

6 ステップ。何かが燃えているときに実行する順序で。

1. 生の反応をキャプチャします。 全身、全ヘッダー、ステータスコード。 app's の解釈ではありません - 実際のバイト。 curl -i または、ネットワーク タブの [copy as curl] です。
2. フォーマットします。 JSON フォーマッタ。 を見て 形 値を見る前に。 必要な分野は存在しますか?
3. すべての不透明な文字列をデコードします。 トークン JWT デコーダ、base64 Blob を通して Base64 コンバーター、 を経由した URL を URLエンコーダ。 不透明な文字列は、驚くほど頻繁に答えを隠します。
4. 時間になる可能性のあるすべての数字を日付に変えます。 タイムスタンプ コンバーター。 最初に桁を数えます。
5. 正常な応答とは異なります。 json 差分。 良い反応がわかっていない場合は、これが救済を開始するためのサインです。
6. 今だけあなたのコードを読んでください。 この時点で、ファイルを開く前に行が分かるでしょう。

順序が重要です。 ステップ 6 が私が始めたところです。その土曜日が 8 時間かかったのはなぜですか。

よくある質問

API をデバッグするための無料のツールは何ですか?

日常の API デバッグには、JSON フォーマッタとバリデーター、JWT デコーダ、UNIX タイムスタンプ コンバーター、差分ツール、URL エンコーダ/デコーダーの 5 つが必要です。 5 つすべてが Toolz.dev で無料で、ブラウザーで完全に実行されます。 署名済み Webhook を使用する場合はハッシュ ジェネレーターを追加し、デプロイが構成主導の場合は YAML バリデーターを追加します。

JWT または API レスポンスをオンライン ツールに貼り付けても安全ですか?

ツールがクライアントサイドの場合のみ JWTはライブ認証情報であり、APIレスポンスは通常は顧客データであるため、サーバーサイドツールは両方を見知らぬ人& #39; sバックエンドに出荷することを意味します。 Toolz.devツールはJavaScriptを使用してブラウザ内のすべての処理を行い、ネットワーク経由で何も送信しません - 貼り付けている間にDevTools& #39; ネットワークタブを開くことで、これを自分で検証します。機密データを使用して使用するツールに対して同じチェックを実行します。

JWT が生成されたばかりなのに、なぜ「期限切れ」と言うのですか?

最も一般的な原因は、単位の不一致です。 ザ・ exp クレームは秒単位で (RFC 7519 はそれを数値として定義)、JavaScript は JavaScript です。 Date.now() ミリ秒を返すので、それらを直接比較すると、すべてのトークンが期限切れに見えるようになります。 トークンをデコードして、読む exp、それをタイムスタンプ コンバーターで実際の日付に変換し、認証コードに触れる前に実際に過去のものかどうかを確認します。

UNIX タイムスタンプが秒単位かミリ秒かを確認するにはどうすればよいですか?

数字を数えます。 10 桁が秒、13 桁がミリ秒、16 がマイクロ秒です。 1970 年に日付が出た場合は、ミリ秒のパーサーに秒を入力し、56122 年に出た場合はミリ秒単位で秒のパーサーを入力します。 2 番目の間違いは、何もエラーを発生しないので、より危険です。

これらのツールを使用して GraphQL API をデバッグできますか?

はい。 GraphQL 応答は JSON であるため、JSON フォーマッタと JSON の差分は変更されず、GraphQL は通常、JWT デコーダでデコードするベアラー トークン認証と同じベアラー トークン認証を使用します。 唯一の本当の違いは、GraphQL が HTTP 200 を返すことです。 errors array は 2xx 以外のステータスではなく、常に本文をフォーマットします。障害はステータス コードではなくペイロード内にあります。

Webhook 署名の検証が常に失敗するのはなぜですか?

ほとんどの場合、プロバイダーとは異なるバイトをハッシュしているからです。 フレームワークが JSON 本体を解析し、ハッシュ前に再シリアル化した場合、空白またはキーの順序が変更され、HMAC は決して一致しません。 RAW リクエスト本文を受け取ったとおりにハッシュし、HTTP クライアントによって追加された末尾の改行をチェックします。

base64 と base64url のエンコーディングの違いは何ですか?

標準の Base64 (RFC 4648 §4) の使用 + あんど / アルファベットとパッドで =。 Base64URL (RFC 4648 §5) は、それらを - あんど _ 通常、パディングをドロップするので、値は URL または JWT に安全に配置できます。 厳密な標準ベース 64 デコーダに Base64URL データを入力すると、エラーまたはガベージが発生します。そのため、専用の JWT デコーダーは、トークンの手作業によるデコードに勝るものがあります。

401 の不正な応答をデバッグするにはどうすればよいですか?

トークンから外に向けて作業します。 デコードして確認してください exp 現在の時間に対して - 期限切れのトークンは最も一般的な原因の1 つであり、クレームを読み取り可能な日付に変換するまで見えません トークンがライブの場合は、 を確認してください Authorization ヘッダー自体: スキームが存在し、正しくつづりが必要です (Bearer <token>、1 つのスペース、引用符なし)、およびターミナルから貼り付けられたトークンは、多くの場合、一致を破る末尾にある改行を運びます。 その後、確認してください aud あんど iss クレームは、別のオーディエンスに対して発行された有効なトークンは、悪いトークンとまったく同じように拒否されるため、API が期待するものと一致します。 それからだけ、サーバーの疑いを持ち始めます。

ライブラリなしで JWT をデコードするにはどうすればよいですか?

JWTはドットで結合された3 つのbase64urlセグメントです.ドット上で分割してからbase64url-最初の2 つ - ヘッダとペイロード - をデコードし,どちらもプレーンなJSONとして出てきます.3 番目のセグメントは署名であり,テキストではなく生のバイトであるため,読みやすいものにデコードしません.これは聞こえるよりも重要です:トークンをデコードすると、それらの主張が真実であるかどうかではなく、主張するものがわかります.署名の検証にはissuer' sキーが必要であり、サーバーコードに属し、決してブラウザツールではデバッグするためにここでトークンを読み取ります; アプリケーションでそれらを検証します.

これらのツールを使用する場合、Postman や Insomnia は必要ですか?

はい - 彼らはさまざまな問題を解決します APIクライアントはリクエストを送信します; これらのツールは応答を読みやすくします 実際には、私はクライアントを使用してリクエストを発射し、生の出力をコピーし、ブラウザツールに移動してフォーマット、デコード、変換、差分を置き換えるのではなく、ワークフロー内で互いに隣り合って座っています。