2.2　REST設計風格

很多人會拿REST與RPC相比較，其實，REST無論是在思想上、在概念上，還是在使用范圍上，與RPC都不盡相同，充其量只能算是有一些相似，應用會有一部分重合之處，但本質上并不是同一類型的東西。

REST與RPC在思想上差異的核心是抽象的目標不一樣，即面向過程的編程思想與面向資源的編程思想兩者之間的區別。面向過程編程、面向對象編程想必大家都聽說過，但什么是面向資源編程呢？這個問題等介紹完REST的特征之后我們再細說。

REST與RPC在概念上的不同是指REST并不是一種遠程服務調用協議，甚至可以把定語也去掉，它就不是一種協議。協議都帶有一定的規范性和強制性，最起碼也有一個規約文檔，譬如JSON-RPC，哪怕再簡單，也有《JSON-RPC規范》[1]來規定協議的格式細節、異常、響應碼等信息，但是REST并沒有定義這些內容，盡管有一些指導原則，但實際上并不受任何強制的約束。常有人批評某個系統接口“設計得不夠RESTful”，其實這句話本身就有些爭議，REST只能說是風格而不是規范、協議，并且能完全符合REST所有指導原則的系統也是不多見的，這一點我們同樣將在后文中詳細討論。

至于使用范圍，REST與RPC作為主流的兩種遠程調用方式，在使用上確有重合，但重合區域的大小就見仁見智了。上一節提到了當前的RPC協議框架都各有側重點，并且列舉了RPC的一些發展方向，如分布式對象、提升調用效率、簡化調用復雜性，等等。這里面分布式對象的應用與REST可以說是毫無關聯；而能夠重視遠程服務調用效率的應用場景，就基本排除了REST應用得最多的供瀏覽器端消費的遠程服務，因為以瀏覽器作為前端，對于傳輸協議、序列化器的可選擇性不多，哪怕想要更高效率也有心無力。而在移動端、桌面端或者分布式服務端的節點之間通信這一塊，REST雖然有寬闊的用武之地，只要支持HTTP就可以用于任何語言之間的交互，不過通常都會以網絡沒有成為性能瓶頸為使用前提，在需要追求傳輸效率的場景里，REST提升傳輸效率的潛力有限，死磕REST又想要好的網絡性能，一般不會有好的效果；對追求簡化調用的場景——前面提到的瀏覽器端就屬于這一類的典型，眾多RPC里也只有JSON-RPC有機會與REST競爭，其他RPC協議與框架，哪怕能夠支持HTTP協議，提供了JavaScript版本的客戶端（如gRPC-Web），也只是具備前端使用的理論可行性，很少有實際項目把它們真正用到瀏覽器上。

盡管有著種種不同，REST與RPC還是引發了很頻繁的比較與爭論，這兩種分別面向資源和過程的遠程調用方式，就如同當年面向對象與過程的編程思想一樣，非得分出高低不可。

[1] JSON-RPC 2.0規范地址：https://www.jsonrpc.org/specification。