Day 16 用 Postman 呼叫別人做好的 API，今天要往前一步——認識 FastAPI，這是接下來要用來自己動手寫後端 API 的工具。角色正式從「呼叫者」換成「提供者」。

FastAPI 是什麼

FastAPI 是一個用 Python 寫的框架，專門用來快速建立 API。

一開始查資料時有點困惑，「框架」到底在幫我省掉什麼？理解之後發現：如果不用框架，要自己處理「怎麼接收使用者傳來的請求」「怎麼解析網址和參數」「怎麼把資料包成正確格式送回去」這些瑣碎又重複的底層工作。FastAPI 把這些都先寫好了，我只需要專心定義「這個 endpoint 收到請求之後要做什麼事」就好。

這個分工方式讓我想起 Day 15 想過的事——當時列出一個 API 除了核心邏輯，還要處理輸入驗證、錯誤回應這些瑣事。今天發現 FastAPI 很大一部分的價值，就是幫忙把這些瑣事處理好。

為什麼選 FastAPI，而不是其他 Python 框架

查資料時發現 Python 寫後端常見的框架不只一個，還有 Flask、Django 這些更早出現的選項。今天整理了幾個 FastAPI 被選中的理由：

自動資料驗證：只要定義好「這個欄位應該是什麼型別」，FastAPI 會自動檢查使用者傳進來的資料符不符合，不符合就自動回傳錯誤，不用自己手動一個一個檢查
自動產生 API 文件：寫好程式之後，會自動生成一個可以直接在瀏覽器測試的介面，某種程度上跟 Postman 的功能有點像，但是內建的
效能較好、對非同步處理支援佳：因為呼叫 LLM 這種動作通常要等待幾秒鐘，非同步處理可以避免一個請求卡住整個伺服器

最後這點特別重要——專題的核心動作是「呼叫 AI、等待回應」，這跟很多框架設計時預設的「快速讀寫資料庫」情境不太一樣，FastAPI 在這方面的設計剛好比較適合這個專題的需求。

今天理解到的核心概念：路由與資料模型

看了幾個範例之後，抓到兩個今天最重要的概念：

路由（Route）：對應到 Day 15 學的 Endpoint 概念，就是「定義某個網址、搭配某個 HTTP Method，會觸發哪一段程式邏輯」。比如之前規劃的情境生成功能，就會對應到一個類似 /generate-scenario 的路由，搭配 POST 方法。

資料模型（Data Model）：這是今天比較新的概念。FastAPI 可以先定義好「這個 API 預期收到的資料長什麼樣」——哪些欄位、分別是什麼型別、哪些是必填。這其實就是把 Day 15 想過的「Request 要包含哪些欄位」這件事,用程式碼的方式明確寫下來。

對照 Day 13 設計的情境生成 Prompt 輸入——中文情境描述、英文程度、選填的加強重點——今天發現這幾個欄位可以直接對應成一個資料模型的定義，前面幾天做的設計決策,到這裡又再一次被直接沿用,不用重新想過。

一個今天修正的誤解

原本以為「寫後端」是一件很龐大的工程，要處理資料庫、使用者系統、權限管理一大堆東西。但今天理解到，今天要做的第一步其實很單純：寫一個 API，收到前端傳來的中文情境和程度，呼叫 Day 13 的 Prompt 去問 LLM，再把結果包成 JSON 傳回去。 資料庫、使用者系統這些,專題目前的範圍根本不需要碰。

這個認知讓接下來要動手寫的範圍一下子具體很多，不會被「後端」這個詞的既定印象嚇到。