2000 年的定義原文、2008 年定義者的公開劃線、2020 年的第三方史觀重建 — REST 這個詞的爭論跨越二十多年、三個階段的一手文獻都還在線上。爭的始終是同一件事：這個詞有明確的原始定義者、業界最通行的用法卻跟該定義相距甚遠。本文讓三方各自把話說完；工程溝通上該怎麼處置這個詞、收在結尾。

原義：REST 是約束推導的結果

Fielding 的博士論文第 5 章給出 REST 的原始定義方式：從 null style 出發、逐一施加六個架構約束 — client-server、stateless、cache、uniform interface、layered system、code-on-demand（optional）— REST 是這組約束共同推導出的架構風格（見 11.C1）。

原義有兩個常被略過的重點。第一、uniform interface 是 REST 跟其他網路架構風格的區別性特徵、它自身再由四個子約束構成：resource identification、manipulation through representations、self-descriptive messages、hypermedia as the engine of application state — HATEOAS 在原義裡是定義的一部分、而非進階選配。第二、論文明文陳述 trade-off：uniform interface 以效率為代價、換取一般性與互動可見性 — 原義自己就把 REST 定位成有成本的選擇、而非普遍最優。

劃線：定義者的公開否定

2008 年、Fielding 在 blog 上對自稱 REST 的 RPC-style API 公開劃線、列出六條規則：協定獨立、不改標準協定、描述精力放在 media type 與 relation name（而非逐 URI 逐方法的文件）、server 擁有自己的 namespace（client 不得假設固定 URI 結構）、resource type 對 client 不可見、所有 application state transition 由 client 從 server 提供的選項中選擇驅動（見 11.C2）。

這篇文章給了爭論一條可操作的判別線：client 需要 out-of-band 文件才能操作的 API、就通不過 Fielding 意義的 REST — 依這條線、絕大多數自稱 RESTful 的 JSON API 都在線的另一側。同一位作者在 2014 年的 InfoQ 訪談把這條立場推進到版本策略：hypermedia 驅動的 API 用執行期演化取代版本號（該立場的展開見 版本策略章 與 11.C14）。

業界慣行的自我辯護

業界這一側的論證同樣完整、代表性的立場文逐條拆解 hypermedia 的收益假設：client 開發者實務上讀文件直打 endpoint、不會跟連結走（解耦收益落空）；hypermedia 格式無共識、「不會出現資料版的瀏覽器這種 generic REST client」；hypermedia 傳遞不了資料語意、文件仍不可免；複雜度與 response 膨脹沒有換到等比收益（見 11.C8、對照組）。結論是保留 stateless 資源設計的收益、捨 HATEOAS — Twitter、Facebook 等大型 API 被引為這條 pragmatic 路線的成功例。

這篇的論證方式是整場爭論的關鍵分野：它把爭點放在收益而非定義 — 主張定義裡有一塊在自己的場景不划算、名詞本身未被攻擊（C8 判讀）。這讓兩方的分歧從「誰對」變成「收益前提在誰的場景成立」— 收益假設的逐條交鋒、主寫在 Hypermedia 與 HATEOAS 復興。

第三方史觀：挪用、但自成合理架構

第三方的歷史考據給了這場爭論一個雙方都不冤枉的定調（見 11.C9、二手來源）：論文寫於 2000 年、談的是 HTTP/1.1 的設計理據、當時「web API」尚不存在；業界在棄 SOAP 時需要一面學術大旗、把 pragmatic 的 HTTP 用法掛上了 REST 的名字；Rails 2007 移除 SOAP 支援是這場轉向的符號性節點。史觀的結論止於此：名字確實被挪用、但挪用後的做法自成合理架構。把這個定調再推一步是本文的判讀：這套慣行 — 資源化 URL、正確的 method 與 status 語意、JSON 表徵 — 缺的只是一個不與原義衝突的名字。

這場爭論對工程溝通的用處

定義權之爭本身沒有工程結論、但它對日常溝通有三個直接可用的產出。第一、跨團隊溝通時把詞說死：「REST」在 API design review 裡是歧義詞、規範文件（11.10 治理 的 guidelines）該明文定義自家用法 — 多數組織的誠實寫法是「HTTP+JSON、資源導向、Richardson Level 2」、而非裸的 RESTful。第二、判別線當設計問句用：「這個 client 需要多少 out-of-band 知識」是好問題、無論最終給出哪一側的答案。第三、引用要對版本：引 Fielding 支持自己的 URL 命名慣例、引到的多半是業界慣行而非原義 — 這類錯位引用在 style guide 裡很常見、寫規範時值得回一手來源核對。

下一步路由