每次您同步 CRM、提取運送更新，或串接兩個 SaaS 工具時，背後其實都是 REST API 在默默扛下大部分工作。大多數人平常不會特別注意，直到出了問題才會發現它有多重要。
有趣的是：即使是開發者之間，對於 API 到底什麼才算「RESTful」也常常充滿混淆。這個詞被過度寬泛地使用，以至於有個 Reddit 討論串直接說白了——「我不覺得自己真正做出過一個完全符合 Roy Fielding 定義的 RESTful API。」 這可是開發者說的，不是商業使用者。這個概念源自 Roy Fielding 在加州大學爾灣分校（UC Irvine）發表的 ，他把 REST 描述為一種 架構風格——一組設計約束——而不是協定、不是產品，也不是下載來就能用的規格書。
不過根據 ，在 API 專業人士之中，REST 的使用率高達 93%。也就是說，幾乎人人都在用，但真正理解其要求的團隊卻出乎意料地少。這篇文章會用淺白方式帶您看懂 REST API 的 6 大核心特性，指出多數團隊最常搞錯的地方，介紹一個可用來自我評估的成熟度模型，並將 REST 與 SOAP、GraphQL、gRPC 做比較。
什麼是 REST API？（白話定義）
REST（Representational State Transfer，表現層狀態轉移）是一組關於軟體系統如何在網路上溝通的設計規則。
更精確地說，它是一種定義約束條件的架構風格——例如無狀態、可快取、統一介面——用來引導客戶端（您的瀏覽器、行動 App，或自動化工具）如何與伺服器（資料所在之處）互動。REST 通常運行在 HTTP 上，也多半回傳 JSON，但 REST 本身並不綁定任何特定協定或資料格式。
您可以把它想成一場晚宴的禮儀規則。REST 不會規定您要上什麼菜、說什麼語言，而是定義您要怎麼傳菜、怎麼再要一份、以及怎麼表示自己用餐結束。兩個遵守相同禮儀的系統，即使從未見過彼此，也能以可預期的方式溝通。
REST 不是什麼： REST 不是您安裝的產品，也不是像 HTTP 或 SOAP 那樣的協定。把 API 稱為「RESTful」，也不代表它完全符合 Fielding 原始提出的所有約束——通常只是表示它使用了資源 URL 與 HTTP 方法而已。「REST-ish」與「真正 RESTful」之間的落差，是業界最大的混淆來源之一，後面我們會再深入談。
6 大 REST API 特性速覽
先快速看重點。Fielding 定義了 6 項約束，API 若要被視為 RESTful，就應遵循這些規則。其中 5 項是必要條件，1 項是選用。
This paragraph contains content that cannot be parsed and has been skipped.
若要把這些約束如何在真實系統中協同運作具體化，可以想像下面這種分層架構：
1Client / Mobile App
2 ↓
3CDN / Edge Cache (e.g., Cloudflare)
4 ↓
5API Gateway (rate limiting, auth, CORS)
6 ↓
7Load Balancer
8 ↓
9Application Servers
10 ↓
11Database / Internal Services客戶端只會與 CDN 層互動，根本不知道後面還有多少層。這就是 Layered System 約束的實際作用——同時也是安全、快取與擴展得以在客戶端無須知情的情況下完成的原因。
接下來，我們逐項拆解。
REST API 特性逐一說明
Client-Server 分離
Fielding 的第一個約束：客戶端（使用者實際互動的部分）與伺服器（資料與邏輯運作的地方）必須分開。他稱這為 關注點分離。
這在實務上有什麼意義？代表一個行動銀行 App 可以徹底重做介面設計，而銀行不需要碰資料庫或交易引擎。 就是例子之一：它透過資源端點提供聯絡人、行銷活動、旅程與推播通知。不論您是在做客製化儀表板、行動 App，還是串接第三方工具，後端都維持不變。
對商業團隊來說，這代表迭代速度更快。前端設計師與後端工程師不需要被綁在同一個發版週期。只要 API 合約穩定，雙方就能各自獨立前進。
無狀態性
請求之間沒有記憶。客戶端每次呼叫伺服器時，都必須包含伺服器處理該請求所需的所有資訊——伺服器不會保留前一次互動的內容。
我常把它想像成打客服專線，每次都得重新把問題講一遍。很煩嗎？當然。但好處也非常大：任何一位空閒的客服都能接手，客服中心也能直接多加 500 人而不用重新設計系統。這就是水平擴展。
從技術角度來看，無狀態代表沒有黏著 session。負載平衡器可以把下一個請求導向任何一台健康的伺服器。即使其中一台當機，其他伺服器也能無縫接手。Fielding 的論文也明確指出，能提升可觀測性（監控工具可各自理解每個請求）、可靠性（故障不會破壞共享 session 狀態）與可擴展性（伺服器可在請求間釋放資源）。
實務上的補充是：真實系統仍然會有驗證 token、購物車、OAuth 流程等機制。重點不是「完全沒有狀態」，而是伺服器不會在自己的記憶體裡於請求之間保存客戶端 session 狀態；這些工作通常交由 token、資料庫與共享快取處理。
可快取性
這個回應能不能重複使用？這就是可快取性要回答的問題。回應應明確聲明自己是否可被快取；如果可以，客戶端與中介層（例如 CDN）就能在未來遇到相同請求時重複利用它，進而降低伺服器負載並提升速度。
HTTP 的做法很直接：像 Cache-Control、ETag、Last-Modified、Expires 這類標頭，會告訴快取多久有效，以及何時需要重新驗證。對商務讀者來說，可以把它想成回應上貼了一張標籤，寫著「這個答案接下來一小時都可用」或「每次都請重新查詢最新資料」。
效能影響是真實存在的。 測試顯示，尾端快取命中回應時間可改善 50–100ms。而 Fielding 自己的論文也記錄了網路流量如何從 1994 年每天 10 萬次請求，成長到 1999 年每天 6 億次請求——快取正是其中關鍵的設計因素。
通常可快取的內容： 產品目錄、公開部落格內容、國家／幣別清單、API 文件。
通常不可快取的內容： 個人儀表板、結帳總額、銀行餘額、管理報表。
統一介面
這是 Fielding 自己稱為區分 REST 與其他架構風格的 核心特徵。它標準化了客戶端與資源互動的方式，讓 API 變得可預期。
這個總體約束下面又包含四個子約束：
- 資源識別： 每個資源都有穩定的 URI。
/customers/123代表一位客戶，/orders/456代表一筆訂單。 - 透過表徵操作資源： 客戶端操作的是資源的表徵（JSON、XML、HTML），而不是伺服器內部物件。
- 自我描述訊息： 請求與回應會帶足夠的中繼資料——方法、狀態碼、內容類型、錯誤細節——讓任何中介層或客戶端都能理解。
- HATEOAS（Hypermedia as the Engine of Application State）： 回應會包含相關動作與資源的連結，讓客戶端不必把每個端點都硬編碼死，就能知道下一步該做什麼。
HTTP 方法對應是統一介面最明顯的一部分：
This paragraph contains content that cannot be parsed and has been skipped.
明確指出 GET 應該是安全的，而 GET、PUT、DELETE 應該是冪等的。GitHub、Stripe、Spotify 這些知名 API 也大致遵循這些模式，因此開發者只要學會一個，就能很快上手另一個。
分層系統
您的客戶端根本不知道自己連的是原始伺服器、CDN 快取、API gateway，還是負載平衡器。這正是重點——每個元件只看到它相鄰的那一層。
這也是為什麼可以做到：
- CDN（例如 Cloudflare）位於 API 前方，負責快取與加速回應
- API gateway（AWS API Gateway、Kong、Apigee）負責驗證、流量限制與配額管理
- 負載平衡器將無狀態請求分散到多台應用伺服器
指出，使用 AWS API Gateway，26% 使用 Azure gateway，31% 同時使用多個 gateway。分層架構不是理論而已，它就是生產環境系統實際的運作方式。
代價是：每多一層，就會多一點點延遲。不過 Fielding 認為，在大多數真實世界系統中，中介層共享快取所帶來的效益，遠大於這些額外成本。
Code-on-Demand（選用）
這是最特別的一項。Code-on-Demand 是唯一可選的 REST 約束：伺服器可以傳送可執行程式碼——例如 JavaScript——即時擴充客戶端功能。
實務上最常見的例子，就是網頁從伺服器載入 JavaScript。不過對大多數由行動 App、後端工作或自動化工具消費的 JSON REST API 來說，Code-on-Demand 幾乎從不使用。API 客戶端通常不希望執行遠端伺服器傳來的任意程式碼。
對多數讀者而言，這個約束比較像註腳。它存在於 Fielding 的模型中，是為了完整性，但日常評估 API 時通常不會成為重點。
多數人最常搞錯的是什麼：大部分 REST API 真的 RESTful 嗎？
這是沒人太想正面談的部分：大多數自稱「RESTful」的正式產品 API，其實只是帶有 REST-ish 慣例的 HTTP JSON API。它們使用資源 URL、HTTP 方法與狀態碼——大致上就這樣而已。r/softwarearchitecture 的一則 Reddit 討論串裡，開發者甚至直接承認自己從沒做過真正符合 Fielding 原始定義的 REST API。另一個 r/learnprogramming 討論則演變成：到底有沒有人能對「RESTful」的意思達成一致？
一份 2026 年研究訪談了 16 位 REST API 專家，發現雖然指引有助於提升易用性，但開發者對嚴格 REST 規則仍明顯存在抗拒，原因包括規範太多，以及與自家組織的實際情況不夠契合。
那麼，這些約束在實務中到底落到哪裡？
This paragraph contains content that cannot be parsed and has been skipped.
為什麼團隊會跳過 HATEOAS： 客戶端開發者通常寧可看 OpenAPI 文件、使用 SDK，也不想在執行時動態追隨連結。HATEOAS 需要穩定的媒體類型、link relation 定義與工作流程建模——短期成本高，而且對多數團隊來說收益並不明確。
實務上的重點是：API 不必 100% 符合 Fielding 原始規範，也能好用。但如果您知道自己跳過了哪些約束、又因此失去了什麼，就能做出更好的設計與整合決策。
Richardson 成熟度模型：您的 API 到底有多 RESTful？
如果「它是不是 RESTful？」這種二元問題讓您覺得不夠實用，那 Richardson 成熟度模型會是更實際的框架。這個模型由 Leonard Richardson 提出，並由 ，它把 REST 的採用分成四個層級。
This paragraph contains content that cannot be parsed and has been skipped.
您在實務中遇到的大多數 API 都落在 Level 2。它們正確使用資源、動詞與狀態碼。這已經足以實用、可互通，且能被工具良好支援。Level 3 才是 Fielding 完整的願景，但採用率仍然不高。
您的 API 落在哪一層？ 您可以問自己：
- API 是否用單一端點處理所有事？（Level 0）
- 每個業務物件是否都有自己的 URI？（Level 1+）
- HTTP 方法與狀態碼是否使用正確？（Level 2）
- 回應是否會告訴客戶端下一步能做什麼，而不必依賴外部文件？（Level 3）
這個模型是我用過最能有效穿透「它到底是不是 REST」爭論的工具。它把二選一的判斷改成一個光譜。
常見 REST API 錯誤（以及如何避免）
我花了不少時間整合第三方 API，累積了一長串讓人頭痛的問題。從開發者論壇看來，這種感受我並不孤單。下面這些反模式最常出現，而且每一個都直接對應到 REST 約束的違反。
This paragraph contains content that cannot be parsed and has been skipped.
要求使用正式的 HTTP 狀態碼，並建議錯誤回應採用 Problem JSON。 則明確規定 Problem Detail 只能用於 4xx/5xx，不可與 2xx 混用。這些不是學術偏好，而是大規模 API 團隊在生產環境中採用的實務標準。
r/learnprogramming 的一則 Reddit 討論裡，有位開發者真心在問：錯誤時永遠回傳 HTTP 200 可以嗎？到了 2026 年這個問題還在被問，只能說這些反模式有多頑固。
REST、SOAP、GraphQL、gRPC：REST API 特性如何比較？
單獨理解 REST 很有用；把它與替代方案一起理解，效果更好。
| 面向 | REST | SOAP | GraphQL | gRPC |
|---|---|---|---|---|
| 協定 / 傳輸 | 架構風格，通常基於 HTTP | 以 XML 為基礎的訊息協定，可用 HTTP、SMTP 等 | 查詢語言／執行環境，通常透過 HTTP | 建立在 HTTP/2 上的 RPC 框架 |
| 資料格式 | 通常是 JSON，也可用 XML/HTML | 僅 XML（WSDL 合約） | 符合查詢形狀的 JSON | Protocol Buffers（二進位） |
| 快取 | ✅ 設計得當時可原生使用 HTTP 快取 | ❌ 複雜，不利 HTTP 快取 | ⚠️ 較難（POST + 單一端點 + 查詢變化多） | ❌ 非以 HTTP 快取為導向 |
| 即時支援 | ❌ 需輪詢／webhook | ❌ 企業訊息模式 | ✅ 訂閱 | ✅ 串流、低延遲 |
| 學習曲線 | 低到中 | 高 | 中 | 中到高 |
| 最適合 | 公開 API、CRUD、網頁／行動整合 | 企業／舊系統、嚴格合約、合規需求 | 複雜查詢、彈性前端、行動 App | 微服務對微服務、內部高效能通訊 |
建議，應根據相容性、資料形狀、操作方式與使用者工具來選擇。
什麼情境該選哪個：
- REST 在您需要廣泛相容性、簡單 CRUD 操作與 HTTP 快取時勝出。它是公開 API 與網頁／行動整合的預設選項。
- SOAP 仍適合企業系統中具有嚴格合約、WS-Security 需求，或不會消失的舊整合場景。
- GraphQL 在前端需要彈性、巢狀查詢，且您想避免 over-fetching 或 under-fetching 時特別好用，這在複雜行動 App 中很常見。
- gRPC 則是為內部微服務通訊而生，低延遲與二進位序列化比瀏覽器相容性更重要。
以真實世界的 REST 範例來看： 使用簡單直接的 POST 端點（/distill 與 /extract）、JSON 請求／回應內容、Bearer token 驗證，以及標準 HTTP 狀態碼（400、401、402、408、422、429、500、502、503、504）。它在不需要 SOAP 合約或 gRPC 複雜度的情況下，示範了生產級 AI 產品中的 REST 特性。它不是 HATEOAS 的展示案例，但對商業團隊與開發者而言，這是一個很容易整合的實用 Level 2 API。
為什麼 REST API 特性對商業團隊很重要
銷售、營運、電商——這些團隊平常都不寫 API 程式碼。但您確實會選供應商、串接工具、打造自動化流程，而 REST API 的品質，會直接影響這些整合到底有多痛苦。
工具整合： 當您的 CRM 要與行銷自動化平台同步時，REST API 的設計會決定同步是穩定還是脆弱。 透過可預期的資源端點管理聯絡人、行銷活動、旅程與推播通知。如果這些端點遵循 REST 慣例，您的 RevOps 團隊就能自動化處理，而不必自己補一堆權宜之計。
電商營運： 管理出貨訂單、追蹤號碼與運送狀態。運送 App 與 fulfillment 工具都依賴這一層。當 API 設計良好——正確的狀態碼、可快取的商品目錄資料、清楚的錯誤訊息——物流流程就能順暢運作。設計不好時，您就會在凌晨 2 點收到莫名其妙的故障。
評估供應商： 了解這 6 項約束，能讓您有一份實用檢查清單：
- API 是否使用標準狀態碼，還是每次失敗都長得像 200 OK？
- 錯誤訊息是否夠具體，讓自動化工具能自行恢復？
- 是否有清楚文件說明 rate limit、分頁與驗證？
- 常見回應能否快取，以降低負載？
資料擷取與自動化： 像 這類工具採用基於 REST 的架構，讓商務使用者能從網站、PDF、圖片中擷取結構化資料，然後匯出到 Google Sheets、Airtable、Notion 或 Excel。Thunderbit 的 用 2 步驟介面處理了背後的複雜性，但底層真正讓整合層穩定運作的，仍是 REST 原則——無狀態請求、JSON 回應、標準錯誤碼。
還有一個值得注意的數據點：Postman 2025 報告發現，只有 會在設計 API 時主動考慮 AI agent，而 51% 的人擔心 AI agent 會帶來未授權或過量的 API 呼叫。隨著自動化與 AI 驅動的工作流程成為商業團隊的標配，可預期的 REST 模式、最小權限 API key 與 rate limit，不再只是開發者的考量，而是營運風險因素。
Thunderbit 如何將 REST 原則應用於商務使用者
我們打造 時，假設大多數使用者永遠不會去讀 REST 規格書——而且也不需要。讓 Thunderbit 好上手的設計選擇，其實都建立在本文提到的那些 REST 特性上。
以下用一個簡短流程說明實際怎麼運作：
- 從 安裝 Chrome 擴充功能，並打開您想擷取資料的網站、PDF 或圖片。
- 點擊「AI 建議欄位」，Thunderbit 的 AI 會讀取頁面，並提出一份結構化欄位表——例如產品名稱、價格、Email，或頁面上出現的任何內容。
- 視需要調整欄位，然後點擊「抓取」。Thunderbit 會自動處理分頁、子頁面與動態內容。
- 將資料匯出到 Google Sheets、Airtable、Notion、CSV 或 Excel——免費，沒有付費牆。
對開發者與自動化流程來說，Thunderbit 的 以 REST 風格 POST 端點提供 /distill（乾淨的 Markdown 擷取）與 /extract（結構化資料擷取），並使用 JSON 主體與標準 HTTP 錯誤碼。若用 Richardson 成熟度模型來看，這是一個相當紮實的 Level 2——有資源、方法正確、狀態碼也有意義。
如果您想更廣泛地探索網頁爬取或資料擷取，我們也寫了更深入的指南：、、以及。
重點整理
- REST 是架構風格，不是協定。 它定義了 6 項約束——client-server、無狀態、可快取、統一介面、分層系統，以及可選的 code-on-demand——來引導 API 設計。
- 大多數「RESTful」API 並非完全 RESTful。 多數落在 Richardson Level 2（資源 + HTTP 動詞 + 狀態碼）。HATEOAS 與 code-on-demand 很少被實作。
- Richardson 成熟度模型是最好的自我評估工具。 它把「是不是 REST」這種二元問題，變成實用的光譜（Level 0–3）。
- 常見錯誤——錯誤卻回 200 OK、什麼都用 POST、缺少快取標頭——依然很普遍。 了解這些約束能幫您辨識並修正這些反模式。
- REST 與 SOAP、GraphQL、gRPC 的選擇不是看誰最好，而是看誰最適合。 REST 主導公開 API 與 CRUD 整合；GraphQL 適合複雜前端；gRPC 擅長內部微服務；SOAP 則在企業與舊系統情境中仍有其位置。
- 商業團隊理解 REST 特性也很有幫助， 特別是在評估供應商、串接工具與建立自動化流程時。像 這樣的工具，正是透過 REST 原則讓資料擷取變得容易，不需要技術背景。
常見問答
REST API 的 6 大特性是什麼？
6 項 REST 約束分別是：（1）client-server 分離、（2）無狀態性、（3）可快取性、（4）統一介面、（5）分層系統，以及（6）code-on-demand（選用）。依照 Fielding 的原始定義，前五項是 API 要被視為 RESTful 的必要條件。
REST 和 RESTful 有什麼差別？
REST 是架構風格，也就是 Roy Fielding 定義的設計約束集合。「RESTful」則是用來描述遵循這些約束的 API。實務上，許多被標示為「RESTful」的 API 只做到一部分，通常有資源、HTTP 方法與狀態碼，但省略了 HATEOAS 與 code-on-demand。
所有 REST API 都會遵循每一項 REST 約束嗎？
不會。大多數正式環境中的 API 會遵循 client-server 分離、無狀態性，以及基本的統一介面（資源 + HTTP 動詞）。可快取性與分層系統的實作則不一致。HATEOAS 很少見，而 code-on-demand 幾乎不會出現在 JSON API 中。
REST 和 GraphQL 有什麼差別？
REST 會透過多個端點暴露資源，並使用標準 HTTP 方法（GET、POST、PUT、DELETE）。GraphQL 通常只使用單一端點，由客戶端在查詢中指定自己要哪些欄位。REST 天生支援較強的 HTTP 快取；GraphQL 則更適合複雜、巢狀資料需求，也能減少 over-fetching。
什麼是 HATEOAS？真的有人在用嗎？
HATEOAS（Hypermedia as the Engine of Application State）指的是 API 回應會包含連結，告訴客戶端下一步可以做什麼，讓客戶端不必把每個端點都硬編碼死。它是 Fielding 對 REST 的核心願景（Richardson Level 3），但在實務上，真正實作它的公開 API 非常少。多數團隊停留在 Level 2，改以文件與 SDK 來支援。
了解更多