時(shí)下隨著架構(gòu)解耦和微服務(wù)架構(gòu)的興起，每一個(gè)開發(fā)者都不可避免要用到REST構(gòu)建API和用REST交互。然而我們真正了解并善用了當(dāng)代REST和超媒體的好處么?本文就和大家一起學(xué)習(xí)了，2020年的REST和超媒體。

概述

REST被認(rèn)為是一堆抽象層，可幫助減少與客戶端開發(fā)人員的交流，同時(shí)使能夠構(gòu)建更堅(jiān)固和一致的應(yīng)用程序。

這可以通過幾種方式來實(shí)現(xiàn)，主要是依靠REST API存在的協(xié)議的現(xiàn)有語義，通常是HTTP。在HTTP中構(gòu)建REST API就要遵循現(xiàn)有的HTTP語義來實(shí)現(xiàn)REST提出要實(shí)現(xiàn)的概念，而不是發(fā)明自己的約定。

客戶端可以查詢Retry-After標(biāo)頭，而不是編寫一堆代碼來了解API可能會(huì)響應(yīng)的每個(gè)應(yīng)用程序錯(cuò)誤，并自己處理錯(cuò)誤的代碼。

開發(fā)者抱怨REST很難，因?yàn)楸仨氁私釮TTP方法及其含義以及不同的狀態(tài)代碼。雖然學(xué)習(xí)HTTP可能需要一些時(shí)間，但HTTP的約定與龐大的工具生態(tài)系統(tǒng)共享。

開發(fā)者一致對(duì)這些技術(shù)很排斥，很多時(shí)候他們更喜歡RPC。對(duì)于許多開發(fā)人員來說，可以在互聯(lián)網(wǎng)上運(yùn)行這些API就足矣，他們可以在上面自己添加操作和約定，這樣他們雖然也獲得了一些需要的功能CRUD(POST, GET, PUT, DELETE = Create, Read, Update, Delete)增刪改查，并丟了REST架構(gòu)可以提供的大量的好處。

"REST是RPC之上的一堆抽象層"嗎?

Richardson的成熟度模型結(jié)構(gòu)圖示如下：

這是Martin Fowler在介紹《Richardson成熟度模型》的文章的總結(jié)圖示。該模型以Leonard Richardson的名字命名，討論API的成熟度。

該圖有一些常見的問題，主要是頂部是" Glory of REST"，底部亂成一團(tuán)。不幸的是，這使REST API看起來像是個(gè)迷宮，而其他所有事物都很亂的。

REST的帶來好處是很明顯的：

• 網(wǎng)絡(luò)上的所有事物都可被抽象為資源(Unify);
• 每個(gè)資源都有統(tǒng)一唯一的資源標(biāo)識(shí)符(URI);
• 使用標(biāo)準(zhǔn)方法操作資源;
• 所有的操作都是無狀態(tài)的;
• 可以通過緩存來提高性能。

另一個(gè)問題是Martin談?wù)摰氖荘lain Old XML，如今，有些人談?wù)摰氖荘OJO(Plain old JSON Objects)。

所有API開發(fā)人員都可以使用API規(guī)范(用于描述數(shù)據(jù)模型的元數(shù)據(jù))，無論他們的范例或選擇的實(shí)現(xiàn)方式如何，因此都應(yīng)將其考慮在內(nèi)。REST人員使用JSON Schema，gRPC人員使用Protobuf，而GraphQL用戶具有GraphQL類型。

改進(jìn)Richardson成熟度模型

我們對(duì)上面提到的Richardson成熟度模型進(jìn)行改進(jìn)，每層簡(jiǎn)要地提到了它啟用的一些功能。

RPC

真正遇到的問題是，最基本形式的RPC通常會(huì)忽略許多HTTP概念。它不會(huì)使用HTTP的統(tǒng)一接口及其完整語義，也不使用HTTP作為傳輸協(xié)議，而僅使用傳輸方面。傳輸協(xié)議可以幫助您知道何時(shí)或是否需要發(fā)出請(qǐng)求，而不僅僅是在網(wǎng)絡(luò)上傳送數(shù)據(jù)。大多數(shù)RPC實(shí)現(xiàn)都與單個(gè)端點(diǎn)交互，并且大多數(shù)交互都使用單個(gè)HTTP方法。很少有通用的HTTP約定只能用于最基本的RPC。

如果RPC遵循特定標(biāo)準(zhǔn)，則可以使用為該標(biāo)準(zhǔn)構(gòu)建的工具，但是通用HTTP約定不適用。

資源

這里有兩個(gè)常見的困惑，首先這不是關(guān)于擁有/bikes， /bikes/abc123而是經(jīng)常使用的標(biāo)準(zhǔn)集合，復(fù)數(shù)和資源CRUD模式。

從技術(shù)上講，資源與端點(diǎn)是一樣的東西，但是有一個(gè)故意的區(qū)別。端點(diǎn)通常被認(rèn)為更像是函數(shù)，其目的是在想做某事時(shí)調(diào)用一個(gè)函數(shù)，但這又是傳輸?shù)拇蠖鄶?shù)傳輸方式，通常是RPC思維的標(biāo)志：調(diào)用某事并執(zhí)行一個(gè)事情。

資源更像是標(biāo)識(shí)符，它是在特定位置的唯一事物，可以被該事物識(shí)別。它是HTTP世界中最終的唯一標(biāo)識(shí)符，盡管可能會(huì)有具有相同字母/數(shù)字ID的不同產(chǎn)品，也有可能UUID也會(huì)沖突。

URI(統(tǒng)一資源標(biāo)識(shí)符)是擁有適用于所有內(nèi)容的唯一。這樣我們可以將特定的標(biāo)頭添加到不同的資源中，這些標(biāo)頭可以與響應(yīng)一起作為元數(shù)據(jù)存儲(chǔ)。

這樣資源可以聲明自己的可緩存性，這是REST談?wù)摰闹匾獌?nèi)容之一。

緩存約束要求對(duì)請(qǐng)求的響應(yīng)中的數(shù)據(jù)被隱式或顯式標(biāo)記為可緩存或不可緩存。如果響應(yīng)是可緩存的，則授予客戶端緩存以將響應(yīng)數(shù)據(jù)重新用于以后的等效請(qǐng)求的權(quán)限。

添加緩存約束的優(yōu)勢(shì)是可以部分或完全消除某些交互，從而通過減少一系列交互的平均延遲來提高效率，提高系統(tǒng)的可伸縮性和用戶感知的性能。

HTTP/1.1中緩存的目標(biāo)是通過重用先前的響應(yīng)消息來滿足當(dāng)前請(qǐng)求，從而顯著提高性能。如果可以在沒有"驗(yàn)證"的情況下重用響應(yīng)，則存儲(chǔ)的響應(yīng)被視為"新鮮的"(與原始服務(wù)器進(jìn)行檢查，以了解緩存的響應(yīng)是否對(duì)該請(qǐng)求仍然有效)。因此，每次重新使用響應(yīng)時(shí)，新響應(yīng)都可以減少延遲和網(wǎng)絡(luò)開銷。當(dāng)緩存的響應(yīng)不"新鮮"時(shí)，如果可以通過驗(yàn)證將其刷新或原始不可用，則該響應(yīng)可以重用。

如果具有唯一的URI，則在HTTP/2中也無痛升級(jí)使用。

HTTP方法

方法為請(qǐng)求中發(fā)生的事情的類型添加了許多重要的語義。如果使用了緩存，則緩存組件將知道它可以緩存GET請(qǐng)求，但是如果對(duì)同一個(gè)資源執(zhí)行POST或DELETE操作，它將知道它應(yīng)該避開它。

像自動(dòng)重試這樣的客戶端邏輯現(xiàn)在成為可能。當(dāng)API花費(fèi)很長(zhǎng)時(shí)間進(jìn)行響應(yīng)時(shí)，重試可以提供幫助，客戶端應(yīng)用程序可能會(huì)針對(duì)請(qǐng)求進(jìn)行保釋，然后重試。使用GET幾乎沒有什么缺點(diǎn)，它是冪等請(qǐng)求，不應(yīng)具有任何破壞性動(dòng)作。

重試POST可能很危險(xiǎn)，因?yàn)榭赡茉谶_(dá)到超時(shí)之前，它可能會(huì)更改數(shù)據(jù)庫中的某些記錄，發(fā)送一些電子郵件，從信用卡中收取費(fèi)用等。

PUT和PATCH會(huì)很好，PUT也是冪等的，只會(huì)消除結(jié)果，并且PATCH通常具有"from"和"to"，這意味著如果第二次發(fā)出請(qǐng)求，則"from"可能會(huì)不匹配。

對(duì)RPC的忠實(shí)擁護(hù)者，!gRPC"HTTP橋"添加了這兩個(gè)抽象層，使其更加像HTTPish。

超媒體控件

超媒體控件是"超媒體作為應(yīng)用程序狀態(tài)引擎"(HATEOAS)的簡(jiǎn)寫，它是一個(gè)非常簡(jiǎn)單的概念。API不僅僅是HTTP上的數(shù)據(jù)存儲(chǔ)，而是成為HTTP上的狀態(tài)機(jī)。它仍然有數(shù)據(jù)，但是它也可以以自我描述的方式提供"下一個(gè)可用動(dòng)作"。

考慮一張發(fā)票，說它是可付款的，而不是需要根據(jù)缺少來確定是否可以付款paid_date，或者可能有status: pending，但是可能會(huì)添加新的狀態(tài)并等待處理并不意味著可以付款?？蛻魬?yīng)用程序中斷或需要版本控制，這兩者都會(huì)浪費(fèi)開發(fā)人員時(shí)間和公司資金。

如果發(fā)票是應(yīng)付賬款，則會(huì)顯示一個(gè)名為"付款"的鏈接，這表示客戶端應(yīng)用程序知道何時(shí)付款，并且只要使用了良好的超媒體格式，客戶端應(yīng)用程序就會(huì)知道如何付款，因?yàn)榭丶梢韵蚍?wù)器發(fā)送HTTP請(qǐng)求之前驗(yàn)證數(shù)據(jù)客戶端，給出哪些數(shù)據(jù)是必須要提供的。

超媒體的最基本層次是將鏈接推到響應(yīng)主體中，但是客戶端必須做很多驗(yàn)證工作才能弄清楚下一步該做什么。此前，只會(huì)是："你有一個(gè)URL和一個(gè)鏈接關(guān)系，這是一個(gè)很好的開始"，但是如今，有很多流行的Hypermedia Formats使這一切變得容易得多。

REST

大多數(shù)自稱為REST的API都沒有最后一層，這意味著它們使用的僅僅是RESTish，或者僅僅是HTTP API。因?yàn)闆]有超媒體控件，就不能叫REST API，這很重要。

可能開發(fā)人員根本不知道HATEOAS(超媒體即應(yīng)用狀態(tài)引擎或超媒體約束)是什么。還有一些人知道，但是認(rèn)為HATEOAS就是要強(qiáng)迫進(jìn)行HTTP請(qǐng)求負(fù)載以獲取相同數(shù)量的數(shù)據(jù)。這時(shí)他們考慮的是傳輸而不是轉(zhuǎn)移，到了時(shí)下快要普及的HTTP/2，即使需要進(jìn)行"更多調(diào)用"，性能影響也可以忽略不計(jì)。

即使到了REST這一層，也不意味著API會(huì)在所有方面都永遠(yuǎn)可靠且完美。粗劣的資源設(shè)計(jì)會(huì)使任何API都難以使用，不論你使用的是哪種范例。GraphQL開發(fā)人員現(xiàn)在開始注意到這一點(diǎn) 。

專注于滿足客戶需求的模型設(shè)計(jì)非常重要，API會(huì)隨著時(shí)間的推移而發(fā)展，修剪掉無用的數(shù)據(jù)，并創(chuàng)建復(fù)合資源以很大程度地減少不必要的網(wǎng)絡(luò)延誤。JSON Schema也剛剛棄用了一個(gè)關(guān)鍵字，這可以使API的開發(fā)變得更加容易。

超媒體和gRPC或GraphQL

在談?wù)摮襟w控件時(shí)，常有這樣的觀點(diǎn)，比如 "這不僅是REST可以做的事情，如果使用HTTP Bridge并添加了鏈接，gRPC可以做到這一點(diǎn)!"

一段時(shí)間以來，著名的GraphQL開發(fā)人員一直在嘗試找到一種將超媒體控件引入GraphQL的方法。如果他們能解決這個(gè)問題，GraphQL不會(huì)準(zhǔn)確地遵循下面這個(gè)圖，但我們可以調(diào)用query和mutation他們分享有或沒有語義足夠靠近HTTP方法和唯一缺少的是資源(URI)來。

對(duì)于GraphQL，缺少URI是一個(gè)更大的問題，這幾乎破壞了他們直接使用HTTP/2 Server Push的機(jī)會(huì)，他們不需要向供應(yīng)商尋求特定的解決方案，例如Apollo訂閱和其他非標(biāo)準(zhǔn)@defer類型的東西。

總結(jié)

無論如何，API并不總是需要超媒體控件。例如，全棧開發(fā)人員經(jīng)常認(rèn)為REST浪費(fèi)時(shí)間，因?yàn)樗麄冎皇窍胍樵償?shù)據(jù)庫并將信息傳遞到表示層。他們不需要將緩存控件附加到消息本身中，他們只需要在客戶端應(yīng)用程序中設(shè)置緩存即可，該客戶端應(yīng)用程序可能在其計(jì)算機(jī)上的另一個(gè)窗口中打開。他們知道何時(shí)使用重試，因?yàn)樗麄兙帉懥藨?yīng)用程序代碼并知道它們的含義，因此他們不在乎是否使用了HTTP語義。這些開發(fā)人員與試圖向可能位于不同樓層或不同大陸的各種客戶團(tuán)隊(duì)提供一致功能的開發(fā)人員完全沒有共同之處，在這些客戶團(tuán)隊(duì)中，傳達(dá)變更或如何推斷狀態(tài)可能是一個(gè)代價(jià)高昂的問題。這些團(tuán)隊(duì)可能正在使用各種網(wǎng)絡(luò)和客戶端工具，例如緩存中間件，服務(wù)監(jiān)控，代理檢查，并且不能限制他們可以使用的工具，因?yàn)檫@可能會(huì)使他們丟掉業(yè)務(wù)。

兩者之間還有其他所有完全有效的方案。并不是所有的汽車都需要防彈玻璃，并非所有的對(duì)話都要有麥克風(fēng)，不是所有的內(nèi)衣都需要有吊帶。同理，也不是所有的API都需要是REST。