概念概覽
graph LR API["/api/v1"] --> Users["/users"] API --> Posts["/posts"] Users --> UserID["/users/:id"] UserID --- GET["GET 取得"] UserID --- PUT["PUT 更新"] UserID --- DELETE["DELETE 刪除"] Users --- GETALL["GET 列表"] Users --- POST["POST 新增"] style API fill:#f96,stroke:#333,stroke-width:2px style Users fill:#bfb,stroke:#333 style Posts fill:#bfb,stroke:#333 style UserID fill:#dfd,stroke:#333 style GET fill:#bbf,stroke:#333 style PUT fill:#fbf,stroke:#333 style DELETE fill:#fbb,stroke:#333 style GETALL fill:#bbf,stroke:#333 style POST fill:#bfb,stroke:#333
什麼是 API？
在往下看之前，先想一個問題：如果每個後端工程師都用自己的方式命名 API，前端要怎麼活？這就是為什麼 REST 會成為主流——它提供了一套「大家都聽得懂的共通語言」。在 REST 出現之前，各家 API 的命名五花八門，光是搞懂對方的 API 就夠頭痛了。REST 的出現，讓 API 設計有了統一的規範，大幅降低了溝通成本。
API 是一種前後端傳遞的介面，讓不同系統之間可以互相溝通。
傳統 API 設計
一般 API 開發出來會長這樣：
| 行為 | Method | Router |
|---|---|---|
| 獲得資料 | - | /getData |
| 新增資料 | - | /createData |
| 刪除資料 | - | /deleteData/1 |
這樣的命名方式通常會帶有 動作 + 流程，好處是有一致的命名規範。但如果把視角拉到你是乙方，接不同公司或不同團隊的 API，你就得把所有的文件弄懂、搞清楚命名規則以後才能開始使用。
什麼是 RESTful API？
RESTful API 的設計理念是：統一路由，用 HTTP Method 區分行為。
| 行為 | Method | Router |
|---|---|---|
| 獲得資料 | GET | /data |
| 新增資料 | POST | /data |
| 更新資料 | PUT | /data/1 |
| 刪除資料 | DELETE | /data/1 |
RESTful 的優點
- 統一規範：所有 API 使用相同的設計原則
- 易於理解：看 Method 就知道這個 API 在做什麼
- IDE 支援：部分 IDE 可以一鍵產生所有 CRUD Methods
RESTful 的限制
- 不是所有情境都需要用到全部的 Methods
- 複雜的業務邏輯可能難以用 REST 表達
- 對於 GraphQL 等替代方案，REST 可能不夠靈活
什麼情況下不該用 REST？
當你的需求是「一次要拿很多不同資源的組合資料」，或是前端需要非常彈性地決定要哪些欄位時，GraphQL 可能是更好的選擇。另外，如果你的場景需要即時雙向通訊（如聊天室），那應該考慮 WebSocket，而不是硬用 REST 來做輪詢。