REST代表Representational State Transfer，這是Roy Fielding在2000年創造的一個術語。它是一種通過HTTP設計松散耦合應用程式的架構風格，通常用于Web服務的開發。REST沒有強制執行任何有關如何在較低級别實作它的規則，它隻是提出了進階設計指南，讓您考慮自己的實作。
在我上一次工作中，我為電信大公司設計了RESTful API已有2年了。在這篇文章中，我将分享我的想法，除了正常的設計實踐。你可能不同意我的幾點，這是完全可以的。我很樂意以開放的心态與您讨論任何事情。
讓我們從标準設計特定的東西開始，以清除'Roy Fielding'希望我們建構的内容。然後我們将讨論我在設計RESTful API時更加注重細節的東西。
架構限制
REST定義了6個架構限制，它們構成了任何Web服務 - 一個真正的RESTful API。
- 統一界面
- 用戶端伺服器
- 無狀态
- 可緩存
- 分層系統
- 按需代碼(可選)
統一界面
由于限制名稱本身适用，您必須為系統内部的資源決定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”。
請注意，上述所有限制都與WWW(Web)密切相關。使用RESTful API，您可以對Web服務執行與Web頁面相同的操作。