為什麼多數現代網站，都離不開 RESTful API？

如果你有在接觸技術文件或跟工程師開會，「RESTful API」這個詞一定出現過不只一次。但很多人其實沒有真的理解它——知道它很重要，不太確定為什麼。

這篇試著用比較直覺的方式解釋。

---

從「系統怎麼溝通」說起

現代的網站或 App，幾乎都不是單一一個程式在跑。前端（你看到的畫面）跟後端（存資料、處理邏輯的地方）是分開的，它們需要一個方式溝通。

這個溝通的橋樑，就是 API（Application Programming Interface）。

API 的形式很多，但目前最主流的一種叫 RESTful API。它不是一個具體的工具或框架，而是一套設計原則——規定前端跟後端應該怎麼交換資料、用什麼格式、遵循什麼邏輯。

---

REST 的核心概念：資源 + 動詞

REST 的思路很直觀：把系統裡的每一種資料叫做「資源（Resource）」，然後用 HTTP 動詞來對這些資源做操作。

以一個簡單的訂單系統為例：

你想做什麼	HTTP 方法	URL
查看所有訂單	GET	/orders
查看單筆訂單	GET	/orders/123
建立新訂單	POST	/orders
更新訂單	PUT	/orders/123
刪除訂單	DELETE	/orders/123

這四個操作——新增、查詢、更新、刪除——就是所謂的 CRUD。幾乎所有系統的核心功能都可以用這四個動作描述，而 RESTful API 就是用這個框架來組織所有的資料操作。

---

為什麼它會變成主流

REST 不是最早出現的 API 設計方式，也不是在所有情境下最好的選擇，但它成為主流是有原因的。

它夠簡單，任何技術背景的人都能理解。 URL 就是資源路徑，HTTP 動詞就是你要做什麼，回傳的是 JSON 格式。前端工程師、後端工程師、甚至非技術的產品人員，都能從 API 文件直接看懂這個 API 在做什麼。

它跟 HTTP 天然契合。 HTTP 本來就有 GET、POST、PUT、DELETE 這些方法，REST 直接利用這套已經存在的基礎設施，不需要另外發明溝通協定。

它是無狀態的（Stateless）。 每次請求都帶著完整的資訊，伺服器不需要記住「上一次這個使用者做了什麼」。這讓系統更容易擴展——你可以同時跑很多台伺服器，每台都能獨立處理請求，不需要共享狀態。

---

跟資料庫的關係

RESTful API 通常是資料庫的「門面」——外部世界不直接碰資料庫，要透過 API 才能存取資料。

這個設計有幾個好處。一是安全：你可以在 API 層控制誰有權限做什麼，不讓任何人直接下 SQL 指令到資料庫。二是彈性：資料庫的結構改了，只要 API 的輸出入格式不變，前端完全感覺不到。三是一致性：不管是手機 App、網頁前端，還是第三方系統要串接，大家都走同一個入口。

---

什麼時候 REST 不夠用

REST 很好，但不是萬能的。

最常被提到的限制是「over-fetching」和「under-fetching」——你要的資料 API 給了一堆你不需要的東西，或者你需要的資料要打好幾次 API 才能湊齊。在資料需求複雜的場景，GraphQL 是一個常見的替代選擇，讓前端精確指定要哪些欄位。

另一個限制是即時性。REST 是請求-回應模式，前端問、後端答。如果你需要伺服器主動推送資料（比如即時通知、即時聊天），REST 就不是最適合的選擇，通常會用 WebSocket 或 SSE（Server-Sent Events）來補充。

---

簡單總結

RESTful API 之所以無所不在，不是因為它技術上最先進，而是因為它足夠直觀、足夠通用、跟現有的 Web 基礎設施高度契合。它讓不同系統、不同技術棧之間的溝通有一套共同語言。

如果你在做的產品需要前後端溝通，或者需要讓別人串接你的服務，從 REST 開始通常是對的決定。等到你碰到它的限制了，再去評估其他方案，那個時候你也會更清楚自己真正需要什麼。