Day 8、Day 9 已經認識過 API 和 JSON 的基本概念，今天照理說不算全新的東西。但今天正式進入第三階段——接下來要動手做 FastAPI 後端、接前端，這些名詞不再只是「理解」，而是要真正拿來用。所以這篇不是重複複習，而是換一個角度重新對齊：上次是為了看懂 Dify、n8n 怎麼運作，這次是為了自己動手蓋一個 API。

從「使用者」視角換成「設計者」視角

Day 8 學這些概念的時候，我是站在「呼叫別人 API」的角色——去 Dify 打一個 POST 請求，拿回一份 JSON。這次不一樣，接下來要做的是設計一個 API 給前端呼叫，角色整個反過來。

這個轉換讓同樣的名詞多了一層新的意義：

Endpoint：上次是「我要打哪個網址」,這次變成「我要規劃出哪些網址給別人打」
Request Body：上次是「我要傳什麼參數進去」,這次變成「我要設計接受什麼參數,並且驗證使用者傳的東西合不合理」
Response：上次是「我會拿到什麼」,這次變成「我要回傳什麼格式,才能讓前端好用」

同一套知識，站在不同位置看，要考慮的事完全不一樣。

GET 跟 POST，今天真正搞懂用哪個的判斷標準

Day 8 只是知道「GET 用來要資料、POST 用來送資料」，這次要落到實際會用到的功能上，才發現判斷標準其實很直覺：這個動作會不會改變伺服器上的東西。

對照專題現在要做的功能：

使用者輸入中文情境、產生英文對話設定 → 這是請伺服器「做一件事、產生新內容」→ POST
之後如果要查詢「使用者過去練習過的情境紀錄」→ 純粹讀取、不改變任何東西 → GET

這個判斷標準比死記規則好用很多——不用去想「這個功能該用哪個方法」，改問「這個動作有沒有讓某個東西被建立或改變」。

重新看 JSON：這次要自己設計 Request 跟 Response 的結構

Day 9 學 JSON 的時候，重點是「看懂」AI 生成的情境資料長什麼樣。這次要多想一層：前端傳進來的 JSON 要長什麼樣，後端回傳出去的 JSON 又要長什麼樣。

回頭看 Day 13 設計的情境生成 Prompt 輸出格式，發現有一個好消息：那份格式其實已經很接近一份合格的 API Response 了——因為 Day 13 就已經按照「結構化、方便被其他程式讀取」的原則在設計。之後把這個功能包進 FastAPI 的時候，Response 的格式應該可以幾乎直接沿用，不用重新設計一套。

Request 的部分則要重新想：前端要傳什麼給後端？初步想到的是使用者輸入的中文情境描述、選擇的英文程度、以及選填的加強重點——這幾個欄位剛好對應到 Day 13 Prompt 裡的那幾個輸入變數。

今天釐清的一個誤解：API 不是只有「呼叫 AI」這一種用途

今天也順便打破一個一直沒細想過的預設：以為做後端 API,主要工作就是「接收使用者輸入、轉呼叫 LLM、把結果傳回去」。但實際想過一輪之後發現，一個完整的 API 除了這個核心功能，通常還要處理：

輸入資料驗不驗證（使用者有沒有漏填必要欄位）
呼叫 LLM 失敗的時候怎麼回應（不能讓前端卡在那邊等）
要不要記錄每次的請求，方便之後除錯