定義個一個 RESTful 系統的時候應該遵循 6 個約束。
它們限制了服務端只能遵循這些約束來處理和響應客戶端請求，但是遵循這些約束服務也可以獲取理想的非函數化的屬性，例如性能、可伸縮、簡單程度、可變能力、可見度、靈活性、可信度。
如果任何一個服務違背了其中一個原則，將不能被稱作 RESTful 系統。
標準的 REST 約束如下：
1.客戶端-服務器
參考內容：客戶端-服務器模型
第一個約束是基於客戶端-服務器架構背後的原則——關注點分離。通過分離用戶界面和數據存儲這兩個關注點，提高了用戶界面跨平臺的可能性，通過簡化服務器組件提高了其可伸縮性。這種分離對於Web來說更加重要的意義是，它使得組件能夠進行獨立修改和擴展，從而能夠支持大量組織的網絡化需求。
2.無狀態
參考內容：無狀態協議
客戶端-服務器通信的一個制約條件就是服務端無法存儲客戶端的上下文執行環境。從任何客戶端發出的每個請求都包含了服務端所必要的信息，但是會話狀態仍留在客戶端。
然而在服務端會話狀態可以輕鬆實現跨服務調用，例如利用數據庫做持久化來保存一段時間內的身份認證信息。客戶端開始發送請求時，它已準備好過渡到一個新的狀態。當一個或多個請求正在發送時，客戶端處於過渡狀態。每個應用程序狀態的表示包含可在下一次客戶端選擇發起一個新的狀態過渡使用的鏈接。
3.可緩存
參考內容：網頁緩存
互聯網中的客戶端和中間層服務器可以緩存響應。因此響應必須直接或間接定義自身是否可被緩存，以免客戶端使用過期的響應數據來發送其它請求。良好的緩存策略可以有效減少客戶端-服務器之間的交互，從而進一步提高系統的可伸縮性和性能。
4.分層系統
參考內容：分層系統
客戶端通常無法判斷它是否是直接連接到後端服務器，還是中間服務器。中間服務器可通過啓用負載平衡，並通過提供共享高速緩存來提高系統的可擴展性。當然也可以強制執行安全政策。
5.按需代碼（可選）
參考內容：客戶端腳本
服務端可以通過傳遞可執行代碼臨時爲客戶端擴展或自定義功能。這方面的例子包括可編譯的組件如Java applets和客戶機端腳本如Java。
6.統一的接口
統一接口約束是設計任何REST服務的基礎。它簡化和解耦的架構，使得每個部分可以獨立被修改。這個統一的接口包含了四個約束：
資源的標識
各種資源都在請求中被確定，例如在使用URI的Web REST系統中，資源本身就表明它們想要被返回給客戶端的格式。例如服務端可以從它的數據庫發送HTML，XML或JSON格式的數據，即使這些都不是服務端的內部數據格式。
通過表述來操作資源
當一個客戶端持有一種資源的表述時，包括任何關聯的元數據，它都有足夠的信息來修改或刪除該資源。
自描述的消息
每條信息都包含足夠的信息來描述如何處理消息本身。例如，一個網絡媒體類型本身就定義了能運行該媒體的解析器（以前被稱爲MIME類型）。
超媒體作爲應用程序狀態的引擎（HATEOAS）
已經初始化URI的REST客戶端應用，應該就像人們訪問了一個Web網站主頁一樣，能夠使用服務器提供的動態鏈接，請求它所需的資源和進行所需的操作。
處理客戶端訪問時，服務端將響應內容也包括當前可用的其它行爲的超鏈接。沒有必要對REST服務的結構或動態信息進行硬編碼來響應客戶端客戶端。