我以前寫 API 比較容易犯一種錯：想一次把前端未來可能會需要的東西都放進 response。表面上很貼心，實際上是把耦合提前做大。
一個回應欄位越多，就越像對外承諾越多。之後只要其中一個欄位的語意改了，前端、行銷頁、匯出流程、快取策略，都可能一起被牽動。
回應越大，承諾越大
所以我現在更偏好小一點的 contract。它有幾個好處：
小 contract 的幾個好處
- 變更影響範圍小
- 文件更容易寫清楚
- 前後端對資料責任更明確
- 測試可以更聚焦，不會每次都比對一大串 JSON
我的判斷方式很簡單
我現在會用一個簡單的判斷：如果某個欄位只是「因為也許之後會用到」，那就先不要放。等真正有使用場景，再用新的 endpoint、query option 或 resource 層去擴充。
小 contract 的另一個價值在於討論。當 response 很大時，團隊其實很難看清楚這個 API 真正服務的是哪個畫面或哪個任務；當欄位夠少時，需求討論會回到比較本質的問題：這個頁面到底需要知道什麼？
這種做法看起來保守，但通常更快。因為你少掉的是未來會回頭維護的負擔，而不是今天少寫的幾行欄位。