開場：從「想」到「按下 Send」

Day 15 把 API、JSON、GET/POST 的概念重新理了一遍，今天要把這些理論實際「打」出去看看。工具是 Postman——一個專門用來測試 API 的軟體，不用寫任何前端介面，就能組出一個 HTTP Request 送出去，直接看伺服器怎麼回應。

其實 Day 7 已經用 curl 指令呼叫過 Dify 的 API 了，但那次是照著範例貼指令，沒有真的理解每個欄位在填什麼。今天用 Postman，一格一格填進去，感覺完全不一樣。

Postman 介面怎麼對應到之前學的東西

打開 Postman 建立一個新的 Request，畫面上的欄位剛好跟 Day 8、Day 15 學的名詞一一對上：

網址列要填的，就是 Endpoint
網址列旁邊的下拉選單選 GET 或 POST，就是 HTTP Method
有一個叫 Headers 的分頁，這裡填 Authorization（API Key）和 Content-Type
有一個叫 Body 的分頁，這裡用 JSON 格式填要送出去的參數
按下 Send 之後，下方會顯示回傳的 Response，還有一個明顯的數字，就是 Status Code

把介面跟名詞這樣對照一輪之後，之前覺得抽象的東西突然變得很具體——原來 Day 8 學的那一串名詞，就是眼前這幾個欄位。

實際跑一次：呼叫 Day 7 做的情境生成器

今天直接拿 Day 7 在 Dify 上做的情境生成器來測試，步驟大致是：

Method 選 POST
網址填入 Dify 給的 endpoint
Headers 加上 Authorization: Bearer app-xxxxxxxxxxxx，以及 Content-Type: application/json
Body 選 JSON 格式，填入情境描述、英文程度這些參數
按下 Send

第一次送出去，Status Code 顯示 401。查了一下才知道這個代碼代表「沒有權限」——後來發現是 Header 那格 Bearer 後面忘記加空格，整串 API Key 被當成無效格式。改好之後重送一次，變成 200，下方也順利跑出情境設定的 JSON。

這個小意外反而是今天最有價值的收穫：親眼看到 401 跟 200 的差別，比單純背「4 開頭是自己的問題」有感多了。

幾個今天特別注意到的細節

Headers 打錯字，錯誤訊息不會告訴你打錯字

一開始以為 401 一定是 API Key 本身錯了，檢查了老半天金鑰本身沒問題,才發現是格式（少一個空格）的問題。這讓我理解到，API 回傳的錯誤代碼只會告訴你「哪一類問題」,不會告訴你「問題出在哪一行」，排查還是要自己一步一步檢查。

Body 的 JSON 格式錯一個逗號,整包直接送不出去

Postman 會在送出前就先檢查 JSON 格式對不對，格式不合法的話會直接標紅提示，不會讓你送出去才發現錯誤。這算是一個很實用的保護機制。

Postman 可以把測試存成一份「集合」

發現 Postman 可以把測試過的 Request 存起來，之後不用每次重新打一次網址和參數。這對之後要重複測試同一個 API（例如 Day 15 提到的錯誤處理情境）會很方便，先存起來，之後可以直接調用同一份設定改參數重測。

為什麼要學 Postman，而不是直接寫程式呼叫

今天也想了一下這個問題:反正之後 Day 18 要用 FastAPI 自己接 AI，為什麼不直接寫程式測試就好？

想通的點是：Postman 讓「呼叫 API」這件事，跟「寫程式邏輯」這件事分開處理。 如果一開始就在程式碼裡呼叫 API，一旦沒收到預期的結果，很難判斷是「API 本身有問題」還是「我程式碼寫錯了」。先用 Postman 確認 API 本身能正常運作、搞懂它要求的格式，之後在 FastAPI 裡寫程式呼叫時，遇到問題才能很快判斷是哪一層出錯。