REST定義了6個架構約束，它們構成了任何Web服務 - 一個真正的RESTful API。(http://restful.p2hp.com/)
統一界面
客戶端服務器
無狀態
可緩存
分層系統
按需代碼（可選）
統一界面
由於約束名稱本身適用，您必須爲系統內部的資源決定API接口，這些資源暴露給API消費者並且遵循宗教信仰。系統中的資源應該只有一個邏輯URI，並且應該提供獲取相關或附加數據的方法。將資源與網頁同步化總是更好。
任何單個資源都不應該太大，並且在其表示中包含每個和所有內容。只要相關，資源應包含指向相對URI的鏈接（HATEOAS）以獲取相關信息。
此外，跨系統的資源表示應遵循某些指導原則，如命名約定，鏈接格式或數據格式（xml或/和json）。
所有資源都應該通過HTTP GET等通用方法訪問，並使用一致的方法進行類似修改。
一旦開發人員熟悉了您的某個API，他就應該能夠對其他API採用類似的方法。
客戶端服務器
這實質上意味着客戶端應用程序和服務器應用程序必須能夠單獨進化而不相互依賴。客戶端應該只知道資源URI，這就是全部。今天，這是Web開發中的常規做法，因此您無需花費任何精力。把事情簡單化。
服務器和客戶端也可以獨立替換和開發，只要它們之間的接口不被改變即可。
無狀態
Roy fielding從HTTP獲得靈感，因此它反映了這種約束。使所有客戶端 - 服務器交互無狀態。服務器不會存儲有關最新HTTP請求客戶端的任何內容。它會將每個請求視爲新的。沒有會話，沒有歷史。
如果客戶端應用程序需要是最終用戶的有狀態應用程序，用戶登錄一次並在此後執行其他授權操作，則客戶端的每個請求都應包含服務請求所需的所有信息 - 包括身份驗證和授權詳細信息。
請求之間不應在服務器上存儲客戶端上下文。客戶端負責管理應用程序的狀態。
可緩存
在當今世界，數據和響應的緩存在任何適用/可能的地方都至關重要。您在此處閱讀的網頁也是HTML頁面的緩存版本。緩存爲客戶端帶來性能改進，併爲服務器提供更好的可擴展性範圍，因爲負載已經減少。
在REST中，緩存應在適用時應用於資源，然後這些資源必須聲明自己可緩存。緩存可以在服務器或客戶端實現。
管理良好的緩存部分或完全消除了一些客戶端 - 服務器交互，進一步提高了可伸縮性和性能。
分層系統
REST允許您使用分層系統體系結構，在服務器A上部署API，並在服務器B上存儲數據，並在服務器C中驗證請求。客戶端通常無法判斷它是直接連接到終端服務器，還是沿途的中介。
按需編碼（可選）
好吧，這個約束是可選的。大多數情況下，您將以XML或JSON的形式發送資源的靜態表示。但是當您需要時，您可以自由地return executable code支持您的應用程序的一部分，例如客戶可以調用您的API來獲取UI小部件呈現代碼。這是允許的。
以上所有限制都有助於您構建真正的RESTful API，您應該遵循它們。儘管如此，有時您可能會發現自己違反了一兩個限制因素。別擔心，你仍在製作一個RESTful API - 但不是“真正的RESTful”。