內(nèi)網(wǎng)API設(shè)計(jì)風(fēng)格對(duì)比

1、內(nèi)網(wǎng)API設(shè)計(jì)風(fēng)格對(duì)比分析選擇最適合業(yè)務(wù)需要的API設(shè)計(jì)風(fēng)格主講人：李錕API的分類 進(jìn)程內(nèi)調(diào)用API 調(diào)用本地開(kāi)發(fā)庫(kù) 本地進(jìn)程間調(diào)用API Linux IPC Android IPC 遠(yuǎn)程調(diào)用API 內(nèi)網(wǎng)API企業(yè)內(nèi)網(wǎng)中的API 外網(wǎng)API面向互聯(lián)網(wǎng)的API 外網(wǎng)應(yīng)用內(nèi)部API 外網(wǎng)公共API什么是架構(gòu)風(fēng)格？ 一種 架構(gòu)風(fēng)格架構(gòu)風(fēng)格 是由一組相互協(xié)作的 架構(gòu)約束架構(gòu)約束 來(lái)定義的。架構(gòu)約束是指應(yīng)用軟件的運(yùn)行環(huán)境對(duì)于架構(gòu)設(shè)計(jì)的約束條件。 應(yīng)用軟件的架構(gòu)設(shè)計(jì)不能脫離其運(yùn)行環(huán)境。 不同的運(yùn)行環(huán)境，決定了應(yīng)用的類型。不同類型的應(yīng)用，會(huì)有不同的架構(gòu)風(fēng)格。 架構(gòu)風(fēng)格比 架構(gòu)實(shí)例架構(gòu)實(shí)例（具體的架構(gòu)）更加

2、抽象。架構(gòu)風(fēng)格與架構(gòu)實(shí)例可以理解為類似于OOP中接口與實(shí)現(xiàn)類之間的關(guān)系。 架構(gòu)風(fēng)格是從建筑學(xué)中借用來(lái)的概念。 來(lái)自美國(guó)建筑大師Christopher Alexander名著建筑的永恒之道（The Timeless Way of Building） 建筑學(xué)中的不同風(fēng)格流派舉例：山西平遙喬家大院、安徽歙縣徽商大宅院、江蘇蘇州拙政園分布式應(yīng)用的架構(gòu)風(fēng)格 服務(wù)設(shè)計(jì)、服務(wù)粒度劃分 面向服務(wù)的架構(gòu)（Service Oriented Architecture，簡(jiǎn)稱SOA） 微服務(wù)架構(gòu)（Microservices Architecture） 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（Domain-Driven Design，簡(jiǎn)稱DDD）

3、分布式應(yīng)用的架構(gòu)風(fēng)格 遠(yuǎn)程調(diào)用API 分布式對(duì)象（Distributed Objects，簡(jiǎn)稱DO） CORBA/RMI/EJB/DCOM/.NET Remoting 遠(yuǎn)程過(guò)程調(diào)用（Remote Procedure Call，簡(jiǎn)稱RPC） SOAP/XML-RPC/JSON-RPC/Hessian/Burlap/Flash AMF/Dubbo RPC 基于Google Protocol Buffer數(shù)據(jù)交換格式的各種RPC協(xié)議 基于Apache Thrift的各種RPC協(xié)議，例如唯品會(huì)的OSP 表述性狀態(tài)移交（Representational State Transfer，簡(jiǎn)稱REST） 將H

4、TTP協(xié)議真正作為一種 應(yīng)用協(xié)議應(yīng)用協(xié)議 來(lái)使用，不再需要基于HTTP的各種RPC協(xié)議 RESTful API符合REST架構(gòu)風(fēng)格要求的API什么是REST？什么是REST？ 由Roy Fielding在其2000年的博士論文架構(gòu)風(fēng)格與基于網(wǎng)絡(luò)應(yīng)用軟件的架構(gòu)設(shè)計(jì)（Architectural Styles and the Design of Network-based Software Architectures）中提出 REST有兩種理解方式 REST是一種分布式應(yīng)用的架構(gòu)風(fēng)格抽象層面 REST是一種為 面向面向互聯(lián)網(wǎng)互聯(lián)網(wǎng)的應(yīng)用軟件的應(yīng)用軟件 量身定制的架構(gòu)架構(gòu)風(fēng)格風(fēng)格 REST正是 Web

5、自身的架構(gòu)風(fēng)格自身的架構(gòu)風(fēng)格，它是Web所取得的巨大成功在技術(shù)層面的原因和理論基礎(chǔ) REST在Web之上是 普適普適的的，同時(shí)適用于Web App和Web API REST是一種分布式應(yīng)用的架構(gòu)設(shè)計(jì)方法具體層面 REST有很多具體的設(shè)計(jì)原則和指導(dǎo)，實(shí)戰(zhàn)性很強(qiáng)REST與RPC兩種API調(diào)用風(fēng)格的區(qū)別 REST對(duì)服務(wù)器端做抽象的基本單元是 資源資源，RPC對(duì)服務(wù)器端做基本抽象的單元是 過(guò)程過(guò)程。REST的建模是以名詞為核心的，RPC的建模是以動(dòng)詞為核心的。 RPC中沒(méi)有統(tǒng)一接口的概念。即使采用相同的協(xié)議，不同的API，設(shè)計(jì)風(fēng)格可以完全不同。RPC也不支持操作語(yǔ)義對(duì)于中間組件的可見(jiàn)性。 RPC中無(wú)法

6、使用超媒體，響應(yīng)的內(nèi)容只包含數(shù)據(jù)。REST中使用了超媒體后，可以實(shí)現(xiàn)很大粒度的交互，交互的效率比RPC更高。 REST支持?jǐn)?shù)據(jù)流和管道，RPC不支持?jǐn)?shù)據(jù)流和管道。 因?yàn)槭褂昧似脚_(tái)中立的消息，RPC的耦合度會(huì)比DO要小一些，但是RPC也常常會(huì)帶來(lái)客戶端與服務(wù)器端的緊耦合。REST中假如使用了超媒體，客戶端與服務(wù)器端可以達(dá)到最小的耦合度。RPC API的優(yōu)點(diǎn) 對(duì)于服務(wù)器端開(kāi)發(fā)人員而言，容易設(shè)計(jì)、開(kāi)發(fā) 便于做集中的監(jiān)控 基于socket的二進(jìn)制RPC協(xié)議，建立連接延遲低、網(wǎng)絡(luò)傳輸效率高 支持有狀態(tài)的長(zhǎng)連接，可進(jìn)行雙向通信，實(shí)時(shí)性好RPC API的缺點(diǎn) 緊耦合 API一旦暴露出去，就難以再做改動(dòng) 沒(méi)有

7、統(tǒng)一的設(shè)計(jì)風(fēng)格 增加了客戶端開(kāi)發(fā)人員的學(xué)習(xí)成本 難以實(shí)現(xiàn)通用的客戶端庫(kù) 通常粒度較小 開(kāi)發(fā)人員很容易混淆遠(yuǎn)程調(diào)用與本地調(diào)用 會(huì)損害用戶（客戶端）可感知的性能Richardson成熟度模型Richardson成熟度模型 第0級(jí)：沒(méi)有明確的資源概念，只有一個(gè)URL，只使用單個(gè)HTTP方法。 第1級(jí)：有明確的資源概念，存在很多URL，只使用單個(gè)HTTP方法。 第2級(jí)：有明確的資源概念，有很多URL，使用HTTP作為操作資源的統(tǒng)一接口。 通常將對(duì)于資源的CRUD式操作分別映射到4個(gè)HTTP方法。 第3級(jí)：在第2級(jí)的基礎(chǔ)上，使用超媒體作為應(yīng)用狀態(tài)的引擎（Hypermedia as the Engine

8、of Application State，簡(jiǎn)稱HATEOAS）。內(nèi)網(wǎng)API暫時(shí)不需要支持HATEOAS 內(nèi)網(wǎng)API運(yùn)行在一個(gè)可控的環(huán)境中 運(yùn)行在同一個(gè)組織的邊界之內(nèi) 服務(wù)器端開(kāi)發(fā)團(tuán)隊(duì)和客戶端開(kāi)發(fā)團(tuán)隊(duì)可以密切溝通 運(yùn)行環(huán)境相對(duì)安全，基本上不會(huì)出現(xiàn)惡意的請(qǐng)求 內(nèi)網(wǎng)API需要做服務(wù)治理 支持HATEOAS的RESTful API不便于做服務(wù)治理 支持HATEOAS相關(guān)的生態(tài)環(huán)境還不夠成熟 通用的媒體類型尚未完全標(biāo)準(zhǔn)化，例如Hydra Core 開(kāi)發(fā)框架、開(kāi)發(fā)庫(kù)尚不成熟 缺少自動(dòng)化測(cè)試工具第2級(jí)RESTful API能解決的問(wèn)題 更加松耦合 改動(dòng)RESTful API比改動(dòng)RPC API更容易 更好的

9、可伸縮性 與基于HTTP的各種RPC協(xié)議相比，對(duì)HTTP的使用更有效率 便于利用HTTP緩存 支持?jǐn)?shù)據(jù)流和管道 易于實(shí)現(xiàn)分層的緩存，提高了服務(wù)器端應(yīng)用的可伸縮性 有統(tǒng)一的設(shè)計(jì)和編程風(fēng)格 服務(wù)器端 客戶端第2級(jí)RESTful API能解決的問(wèn)題 測(cè)試更容易，可以使用各種HTTP測(cè)試工具 Postman/ Advanced REST Client curl/wget SoapUI Pro Jmeter ab/httperf/curl-loader 瀏覽器 最好的互操作性 基于HTTP協(xié)議本身，幾乎所有編程語(yǔ)言都能支持第2級(jí)RESTful API不能解決的問(wèn)題 不支持有狀態(tài)的長(zhǎng)連接，無(wú)法進(jìn)行雙向通信

10、，實(shí)時(shí)性較差 讓服務(wù)器端應(yīng)用開(kāi)發(fā)人員早點(diǎn)下班 把輕松留給客戶端應(yīng)用開(kāi)發(fā)人員，把困難留給自己佛祖 把困難留給客戶端應(yīng)用開(kāi)發(fā)人員，把輕松留給自己人渣 設(shè)計(jì)開(kāi)發(fā)領(lǐng)域模型 DDD是設(shè)計(jì)開(kāi)發(fā)領(lǐng)域模型的利器 DDD與REST是互補(bǔ)的關(guān)系，可相互支持在RPC和REST兩種風(fēng)格之間如何做取舍 根據(jù)服務(wù)所實(shí)現(xiàn)的業(yè)務(wù)邏輯變化的頻繁程度 業(yè)務(wù)邏輯變化頻繁，必須實(shí)現(xiàn)松耦合：選擇REST 業(yè)務(wù)邏輯固定，變化非常少，可以接受緊耦合：選擇RPC 根據(jù)對(duì)于延遲、網(wǎng)絡(luò)傳輸效率、實(shí)時(shí)性的要求 必須確保低延遲、網(wǎng)絡(luò)傳輸效率高、實(shí)時(shí)性：選擇RPC 對(duì)延遲、網(wǎng)絡(luò)傳輸效率、實(shí)時(shí)性要求不高：選擇REST 根據(jù)對(duì)可伸縮性的要求 對(duì)可伸縮性要

11、求非常高：選擇REST 對(duì)可伸縮性要求不高：選擇RPC對(duì)于HTTP的常見(jiàn)誤解 瀏覽器只支持GET/POST方法 HTML表單僅支持GET/POST方法，但是可以通過(guò)附加參數(shù)(例如_method)的方式模擬PUT/DELETE請(qǐng)求 XMLHttpRequest對(duì)象GET/POST/PUT/DELETE 4種方法均可支持 未遵循HTTP協(xié)議的指導(dǎo)誤用HTTP方法 GET方法：安全的、冪等的 POST方法：不安全的、不冪等的 PUT/DELETE方法：不安全的、冪等的對(duì)于HTTP的常見(jiàn)誤解 過(guò)度使用GET方法 敏感信息位于URL中，不夠安全 容易受到爬蟲(chóng)的傷害 過(guò)度使用POST方法 例子：SOAP等

12、RPC風(fēng)格的調(diào)用協(xié)議 一個(gè)方法承擔(dān)了過(guò)多職責(zé) 沒(méi)有充分利用HTTP的優(yōu)勢(shì)對(duì)于HTTP的常見(jiàn)誤解 HTTP是一種RPC風(fēng)格的協(xié)議 事實(shí)：HTTP其實(shí)是一種REST風(fēng)格的協(xié)議 統(tǒng)一接口是REST與RPC兩種風(fēng)格協(xié)議的主要區(qū)別 HTTP是一種“傳輸”協(xié)議（transport protocol） 被錯(cuò)誤翻譯為“超文本傳輸協(xié)議” 事實(shí)：HTTP其實(shí)是一種“移交”協(xié)議（transfer protocol）。TCP才是傳輸協(xié)議，對(duì)傳輸這件工作已經(jīng)做的很好了。 傳輸協(xié)議和移交協(xié)議的區(qū)別 傳輸協(xié)議做的是底層搬運(yùn)比特之類的苦力活，不包含操作的語(yǔ)義 移交協(xié)議做的事情比傳輸協(xié)議更高級(jí)，包含了操作的語(yǔ)義對(duì)于HTTP的常

13、見(jiàn)誤解 HTTP不具備互操作性 因此需要在HTTP之上設(shè)計(jì)SOAP這種“簡(jiǎn)單”的協(xié)議（事實(shí)上很復(fù)雜） 事實(shí)：充分利用好HTTP，已經(jīng)能夠得到足夠好的互操作性，在很多場(chǎng)合甚至比使用SOAP更好對(duì)于REST的常見(jiàn)誤解 REST只適用于面向機(jī)器的Web API，不適用于面向人類的Web App 事實(shí)：REST在Web上是普遍適用的 直接使用HTTP的API就是RESTful API 事實(shí)：在SOAP與真正的RESTful API之間還有廣大的中間地帶 只達(dá)到Richardson成熟度模型第0級(jí)的API不是RESTful API REST只不過(guò)是更漂亮的URI設(shè)計(jì) 事實(shí)：這僅僅是REST的一個(gè)外在特征

14、而已對(duì)于REST的常見(jiàn)誤解 統(tǒng)一接口并不重要 HATEOAS并不重要 事實(shí)：這兩個(gè)方面都是REST架構(gòu)風(fēng)格的核心特征 至少需要實(shí)現(xiàn)統(tǒng)一接口，否則可以確定是冒牌的RESTful API 統(tǒng)一接口只能使用HTTP實(shí)現(xiàn) 事實(shí)：HTTP僅僅是實(shí)現(xiàn)REST架構(gòu)風(fēng)格的一種方式 其他符合REST統(tǒng)一接口的例子：擴(kuò)展了HTTP協(xié)議的WebDAV協(xié)議支持第2級(jí)RESTful API開(kāi)發(fā)的Java開(kāi)發(fā)框架 不支持JAX-RS規(guī)范的開(kāi)發(fā)框架 Spring MVC Struts 支持JAX-RS規(guī)范的開(kāi)發(fā)框架 Jersey RESTEasy Restlet Apache CXF內(nèi)網(wǎng)RESTful API要解決的現(xiàn)實(shí)問(wèn)題 性能：延遲、網(wǎng)絡(luò)傳輸效率 大多數(shù)情況下，建立連接所消耗的時(shí)間，與服務(wù)業(yè)務(wù)邏輯的IO操作相比非常小 可升級(jí)到HTTP/2，HTTP/2極大改善了HTTP/1.1的性能 服務(wù)治理 服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn) 自動(dòng)負(fù)載均衡 流量控制 服務(wù)質(zhì)量 版本化 可在URL中加版本號(hào)參考圖書(shū)資料 RE