用戶端應用程式 (例如行動應用程式、網路瀏覽器或其他伺服器) 會向 API 發出請求，要求執行動作。該要求會傳送至特定網址，當中包含 HTTP 方法、帶有中繼資料的標頭，有時也會包含帶有資料的要求主體。

伺服器會接收並驗證要求，確認用戶端已通過驗證，有權執行要求的操作。接著，伺服器會處理要求，例如從資料庫擷取資料、建立新資源或更新現有資源。

處理要求後，伺服器會將回應傳回給用戶端。這個回應包含用來表示結果的 HTTP 狀態碼 (例如「200 OK」代表成功、「404 Not Found」代表資源不存在、「401 Unauthorized」代表安全性問題)，以及回應主體中的要求資料。

用戶端與伺服器之間傳輸的資料，是資源狀態的「表示法」。JSON (JavaScript Object Notation) 是最常見的資料格式，因為它精簡、人類可讀，且便於程式設計語言剖析。

REST 的強大功效和擴充性源自一組架構限制，這些限制規範了 REST 的設計樣式，符合這些限制的系統即稱為「符合 REST 樣式」(RESTful)。

資源是 REST 的基礎概念，這種物件具有類型、相關資料、與其他資源的關係，以及一組可操作資源的方法。舉例來說，在電子商務 API 中，「產品」或「顧客」就是資源的一種。

每個資源都有專屬 URI，設計良好的 API 通常採用簡潔、描述性強且一致的 URI 來識別資源。舉例來說，/users 可能用來識別使用者集合，而 /users/123 則用來識別 ID 為 123 的特定使用者。

用戶端不會直接與資源互動，而是與資源的表示法互動。最常見的表示格式是 JSON，但也可以使用 XML 或 HTML 等其他格式，這有助於彈性表示資源狀態。

用戶端傳送給伺服器的每個要求，都必須包含伺服器理解及處理要求所需的所有資訊。伺服器不會在每個要求之間，儲存任何用戶端結構定義或工作階段狀態。這項限制讓 REST API 具備高度擴充性，因為任何伺服器都能處理任何要求。

用戶端與伺服器分開，API 做為兩者之間的介面。藉由分離關注點，獨立發展用戶端應用程式和伺服器端應用程式。

REST 的用戶端與伺服器之間須有統一介面。實務上會使用標準 HTTP 方法和超媒體即應用程式狀態引擎 (HATEOAS)，並以 URI 識別資源來做到這點。

應將伺服器回應定義為可快取或不可快取。如果回應可快取，用戶端或中介服務就能將該回應重複用於後續的相同要求，大幅提升效能並減輕伺服器負載。

用戶端與 REST API 連線時，通常無法判斷自己是直接連線至終端伺服器，還是途中的中介伺服器。在架構中導入 API 閘道、負載平衡器等中介伺服器，可提升擴充性、安全性和效能。

REST API 常用於行動裝置的天氣應用程式。這類應用程式會從公開天氣 API 擷取特定地點的目前天氣資訊。

具體來看，用戶端應用程式會向 API 端點發出 HTTP GET 要求，其中包含位置和用於驗證的 API 金鑰。

伺服器會處理要求、擷取指定地點的天氣資料，並傳回 JSON 回應。

在微服務架構中，「產品」服務必須先從「庫存」服務取得最新價格，才能在電子商務網站上顯示。

因此，產品服務會向庫存服務的 API 端點發出內部 HTTP GET 要求，以取得特定產品 ID。

庫存服務會查詢目前的價格，並傳回簡單的 JSON 回應。