We FALL ASleep At Night, We Do REST Right

• We Do Sleep At Night, We Do REST Right
  • 前言
  • REST 起源
  • REST 限制
    • 用戶端 - 服務端
    • 無狀态
    • 緩存
    • 統一接口
    • 分層系統
    • 按需代碼
  • 統一接口限制
    • 資源識别
    • 通過表述來操作資源
    • 自描述的消息
    • 超媒體作為應用狀态引擎
  • Richardson 成熟度模型
  • 總結
  • 有效的參考文檔

Github 同步發表連結

筆者在上一篇文章中提過，任何一種非“強制性”限制同時也沒有“标杆”工具支援的開發風格或協定，最後都會在不同的程式員手中得到不同的诠釋，微服務是如此，DDD 是如此，筆者把它稱為技術思想上的“康威定律”。不出意外的，REST 同樣難逃此劫。光是在學習和收集資料的過程中，筆者就已經見過不下十多篇此類了解，甚至于在 url 中使用短劃線或下劃線連接配接單詞也是衆口難調。

盡管這隻是小事。

微軟也釋出過關于如何設計 REST API 的開發指南，但是不幸的是，REST 的創始人 Roy Fielding 認為微軟的 REST API 規範與 REST 沒有多大關系。

“即使是我最糟糕的 REST 描述也比微軟的 API 指南提供的總結或參考要好很多。”

那什麼才是正确的 REST 描述呢，或者說，REST 是什麼。本文的創作動機便是希冀于解決這樣一個問題。

本文假設讀者已經具備基本的 REST 和 Web 知識，哪怕你們現在認為 HTTP API 就是 REST API 也可。

REST 英文全稱為 Representational State Transfer，又名“表述性狀态移交”，是由 Roy Fielding 在《架構風格與基于網絡的軟體架構設計》一文中提出的一種架構風格（Architectural Style）。而在這篇 REST 聖經問世之前，R.F 博士就已經參與了 HTTP 1.0 協定規範的開發工作（1996年），并且負責了 HTTP 1.1 協定規範的制定（1997年）。

一種架構風格由一組準确命名的，互相協作的架構限制組成。當我們在談論 REST 本質的時候，我們談論的其實是架構限制。

REST 用以指導基于網絡的分布式超媒體系統的設計和實作，Web（即網際網路）就是一種典型的分布式超媒體系統。可以确定的是，在制定 HTTP 協定的過程中，R.F 博士就已經以 REST 架構風格作為指導原則來完成相關工作。論文中提到了以下内容：

“在過去的6年中，我們使用 REST 架構風格來指導現代 Web 架構的設計和開發。這個工作是與我所創作的 HTTP 和 URI 兩個網際網路規範共同完成的，這兩個規範定義了在 Web 上進行互動的所有元件所使用的通用接口。”

“自從1994年起，REST 架構風格就被用來指導現代 Web 架構的設計與開發。”

“開發 REST 的動機是為 Web 的運轉方式建立一種架構模型，使之成為 Web 協定标準的指導架構。”

“REST 的第一版開發于1994年10月至1995年8月之間，起初，在我編寫 HTTP/1.0 規範和最初的 HTTP/1.1 建議時，将它用來作為表達各種 Web 概念的一種方法……”

Web 架構規範主要包括 HTTP， URI 和 HTML 等。

是以我們也不難了解為什麼 REST 與 Web 和 HTTP 能夠結合得如此緊密。盡管直到2000年，這隻“雞”才在下完雞蛋後，出現在了世人面前。

無論是否願意承認，REST 一開始就是為 Web 而服務的，可以這麼說的是，REST 是現代 Web 的架構風格，Web 也是 REST 最典型和最成功的案例。包括在 R.F 博士的論文中，他也是在解決現代 Web 需求（無法控制的可伸縮性和獨立部署）的過程中而逐漸推導出 REST。前文已經提到一種架構風格是由一組準确命名的，互相協作的架構限制組成。而所謂架構限制，便是這個推導過程中最重要的産物。甚至高于 REST 本身。

早先的 Web 與 REST 所描述的模型有着大量出入，然而正是在對應的 HTTP 和 URI 規範出爐後，才有了所謂“現代 Web”的說法。筆者更願意把“現代 Web”的定義期限定為1996年後。

設計與實作上的關注點分離。

在用戶端沒有發起請求時，伺服器并不知道它的存在。同樣的，伺服器無須維護目前請求之外的用戶端狀态，進而改善伺服器的可伸縮性。Session 和 Cookie 都是“需要”被抛棄的。

如果有些應用狀态重要到伺服器需要去關心，那它應該成為一個資源。

對于用戶端而言，使用緩存則是維護狀态和提升性能的更好做法。

使 REST 架構風格差別于其他基于網絡的架構風格的核心特征是，它強調元件之間具有一個統一的接口。實作與他們所提供的服務是解耦的，這促進了獨立的可進化性。同時這也引申出了其他的限制：資源識别；通過表述來操作資源；自描述資訊；超媒體作為應用狀态引擎（即 HATEOAS）。下文會專門說明。

“分層系統”限制在“客戶 - 服務端”限制的基礎上增加了代理元件和網關元件。盡管筆者認為代理和網關都不是重點，“分層系統”限制更注重的是“在用戶端和服務端之間添加一個元件應該是一個透明操作”，元件隻能“看到”與其互動的相鄰層（是不是想到了[迪米特法則][5]），使用層級來封裝服務，同時能夠支援負載均衡和諸如安全性檢查的功能。

這是六大限制中唯一的可選限制。REST 允許用戶端通過下載下傳并執行腳本或其他形式的代碼，對用戶端的功能進行擴充，進而提高用戶端的靈活性和性能。通俗點說，HTML 中的 `