什麼是 REST 架構風格？
REST（Representational State Transfer）是一種軟體架構風格，旨在透過標準化的 HTTP 協定來進行資源操作。它並非一套嚴格的規範，而是一組設計原則，讓系統能夠達到高擴充性與低耦合。
在 RESTful API 中，每一個 URL 都代表一個「資源」（Resource），透過 HTTP 動詞來決定對資源的操作行為，是現代 Web 服務的基石。
REST 的核心在於將業務邏輯抽象化為資源，而非動作。例如使用 /users 而非 /getUsers。
HTTP 動詞與資源操作對應
REST API 強烈依賴 HTTP 的標準動詞來進行 CRUD 操作，這種一致性讓開發者能更直觀地理解 API 的行為。
| HTTP 動詞 | 對應動作 | 常見回傳狀態碼 |
|---|---|---|
| GET | 讀取資源 | 200 OK |
| POST | 建立資源 | 201 Created |
| PUT | 更新資源 | 200 OK |
| DELETE | 刪除資源 | 204 No Content |
無狀態（Stateless）通訊的重要性
REST 的一個關鍵原則是無狀態性。伺服器不需要儲存客戶端的上下文資訊，每一次的請求都必須包含所有必要的資訊，例如認證 Token。
這種設計讓伺服器可以輕鬆進行負載平衡，因為任何一台伺服器都能處理來自同一個客戶端的請求，不會因為 Session 遺失而導致服務中斷。
資源 URI 的設計藝術
良好的 URI 設計應該清晰且具備層次感。建議使用複數名詞來代表資源，並避免在 URI 中包含動詞。
- 推薦：GET /orders/123/items
- 避免：GET /getOrdersByUserId?id=123
- 層次化：/projects/{id}/tasks
狀態碼的正確使用
狀態碼是 API 與客戶端溝通的唯一橋樑。正確使用狀態碼能有效減少除錯時間，並提升開發體驗。
- 2xx：請求成功。
- 4xx：客戶端錯誤，如 400 Bad Request 或 401 Unauthorized。
- 5xx：伺服器內部錯誤。
始終使用標準 HTTP 狀態碼，不要在 response body 中自定義錯誤碼，以免混淆前端整合。
版本控制策略
隨著業務演進，API 勢必會變更。常見的策略包含在 URL 中加入版本號（如 /v1/users）或是透過 Header 進行版本控制。
這能確保舊版客戶端在系統升級時不會崩潰，提供穩定的服務環境。
快取機制與效能優化
REST API 利用 HTTP 的快取標頭（如 ETag 或 Cache-Control）來減少伺服器負載。透過適當的快取策略，可以顯著降低網路傳輸量與延遲。
設計良好的 API 應明確標示資源是否可快取，讓 CDN 或瀏覽器能有效運作。