如果每個後端工程師都用自己的方式命名 API，前端要怎麼活？REST 就是那套「大家都聽得懂的共通語言」。
先講結論
RESTful API 的核心理念：統一路由，用 HTTP Method 區分行為。不用記每個 API 叫什麼名字，看 Method 就知道它在幹嘛。對大多數 Web 應用來說，REST 仍然是最務實的 API 設計方式。
傳統 API 的痛
在 REST 出現之前，API 命名是各家各搞：
| Method | 路由 |
|---|---|
| POST | /getData |
| POST | /createData |
| POST | /deleteData/1 |
A 公司叫 getData，B 公司叫 fetchUser，C 公司叫 query_all_items。你接到一個新 API，第一件事不是串接，而是翻文件搞清楚命名規則。光是搞懂 API 就夠你喝一壺了。
RESTful 怎麼做
REST 的做法很直覺：路由只描述「資源」，行為用 HTTP Method 表達。
| 行為 | Method | 路由 |
|---|---|---|
| 取得所有使用者 | GET | /users |
| 取得單一使用者 | GET | /users/1 |
| 新增使用者 | POST | /users |
| 更新使用者 | PUT | /users/1 |
| 刪除使用者 | DELETE | /users/1 |
看到了嗎？路由都是 /users，差別只在 Method。不管哪個團隊寫的 REST API，你看到 GET /users/1 就知道是「取得 ID 為 1 的使用者」，不需要翻文件。
這就是為什麼 REST 成為主流——它大幅降低了溝通成本。
REST 的好和不好
好的部分：
- 看 Method 就知道在幹嘛，不用猜 API 名稱
- 大部分 IDE 和工具都支援一鍵產生 CRUD
- 學習門檻低，前後端溝通效率高
不好的部分：
- 不是所有情境都能優雅表達。「把使用者的第三個地址設為預設」——你告訴我這個要用哪個 Method 配哪個路由？
- Over-fetching：
GET /users/1回傳所有欄位，但你只需要名字和頭像 - Under-fetching：要拼出一個頁面需要打三個 API（使用者、文章、留言）
什麼時候不該用 REST？
如果你的需求是「一次要拿很多不同資源的組合資料」，或是前端需要非常彈性地決定要哪些欄位——GraphQL 可能更合適。
如果你需要即時雙向通訊（聊天室、股票行情）——用 WebSocket，別硬用 REST 做輪詢。
如果前後端都用 TypeScript——tRPC 讓你連 API 文件都不用寫，型別直接從後端推導到前端。
但對大多數團隊來說？REST 就夠了。不要因為「GraphQL 比較潮」就換，沒有真正的痛點就不需要換。
REST 不是最完美的方案，但它是最多人看得懂的方案。在軟體工程裡，「大家都懂」比「技術最優」更有價值。