API開發工具箱：更快除錯，更早上線

下午3點，你的API回傳了401。Token看起來是有效的。端點是對的。請求標頭也看著沒問題。

把JWT貼到解碼器裡，問題立刻浮現：exp聲明在12分鐘前過期了。Token更新邏輯有個bug。

5秒鐘的解碼剛剛省下了一小時盯程式碼的時間。

JWT除錯是每天的工作

如果你使用任何現代API，就會不斷接觸JWT。登入令牌、服務間驗證、OAuth流程——到處都是。

問題是JWT看起來像一串無意義的亂碼：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

它有什麼聲明？什麼時候過期？用什麼演算法簽名的？光看是看不出來的。

貼上令牌，立刻看到標頭、載荷和過期時間。不用安裝函式庫，不用寫程式碼。直接給你答案。

HTTP狀態碼：不只200和404

快說——401和403有什麼差別？502和503呢？什麼時候該回傳409，什麼時候回傳422？

大多數開發者知道常見的狀態碼，但API會回傳幾十種不同的狀態碼。當你收到一個意想不到的429或令人困惑的307時，需要準確知道它的含義。

HTTP狀態碼參考告訴你每個代碼的含義、使用情境和常見原因。比Google搜尋快，而且不用在Stack Overflow的討論中篩選。

JSON格式化不是選配

API發送JSON，API接收JSON。大多數情況下，JSON以一行壓縮的、沒有空格的形式到達。

{"users":[{"id":1,"name":"Alice","roles":["admin","editor"],"settings":{"theme":"dark","notifications":{"email":true,"push":false}}}]}

試試在裡面找一個遺漏的逗號。或者檢查某個巢狀欄位是否存在。或者比較兩個回應。

貼上壓縮的JSON，得到適當縮排的格式化結果。現在你可以真正閱讀它、發現錯誤、比較結構了。

Base64：驗證標頭的秘密

API驗證經常涉及Base64編碼。Basic Auth標頭是username:password的Base64編碼。JSON載荷中的二進位資料用Base64編碼。憑證內容、Webhook簽名、加密值——都是Base64。

當出問題時，你需要解碼實際發送的內容。或者編碼一個新值來測試。

Base64編碼/解碼器雙向即時處理。貼上編碼字串，看到原始值。輸入新值，得到編碼版本。

常見除錯情境：Basic Auth標頭失敗了。解碼後發現密碼末尾有個換行字元。在程式碼中找到這個問題要花更長的時間。

URL編碼會變得棘手

帶特殊字元的查詢參數需要URL編碼。空格變成%20（或+），&號變成%26，斜線變成%2F。

這在以下情況很重要：

• 建構包含使用者輸入的搜尋端點
• 查詢參數本身包含URL（回呼URL、重新導向URI）
• 除錯參數為什麼解析不正確
• API金鑰包含特殊字元

URL編碼/解碼器精確顯示編碼/解碼後的樣子。在除錯OAuth回呼URL時特別有用，因為這些URL經常是「URL中的URL」，雙重編碼後變得不可讀。

真實的除錯流程

這些工具如何融入實際的API除錯過程：

1. 請求失敗 — 檢查HTTP狀態碼含義
2. 驗證問題？ — 解碼JWT檢查聲明和過期時間
3. 載荷問題？ — 格式化JSON檢查結構
4. 標頭問題？ — 解碼Base64驗證標頭
5. URL解析？ — 解碼URL檢查參數編碼

每個步驟只需幾秒。替代方案——寫一次性腳本、安裝CLI工具或翻文件——需要幾分鐘到幾小時。

保持開啟

我把這些工具放在瀏覽器的釘選分頁裡。不是因為我不能在Python裡做Base64編碼或在VS Code裡格式化JSON。我可以。但切換到終端機、寫個快速腳本、執行它——這會打斷除錯的流程。

這些工具就是除錯速度本身。貼上，看結果，理解問題，修復程式碼。最快的除錯循環。

---

API開發50%是寫程式碼，50%是搞清楚為什麼寫的程式碼沒有按預期運作。合適的瀏覽器工具不是取代IDE或除錯器——而是透過讓「搞清楚」的部分更快來補充它們。