原文：There is No REST API ? ?

譯者：杰微刊兼職翻譯汪建 ? ? ?

作者：Howard Dierking

最近我花了一些時(shí)間和我的團(tuán)隊(duì)從API的角度來聊了REST的話題，同樣也討論了如何利用諸如違反了REST的最重要原則的Swagger技術(shù)去創(chuàng)建API。正如我在討論中說的，那就是REST風(fēng)格不是用來描述API。REST描述了整個(gè)系統(tǒng)的架構(gòu)特性，用于描述此該系統(tǒng)包含了所有哪些不同組成的部分。它嘗試基于組件對系統(tǒng)提出系統(tǒng)級別的要求，甚至是對系統(tǒng)不起作用的一層。

“我們對于REST風(fēng)格最大的幫倒忙的行為之一就是我們在REST后面添加了API字眼！”

目前我見過幾個(gè)不同公司的處理場景，這些公司在最純粹的定義上將一個(gè)服務(wù)搭建成REST風(fēng)格，客戶端通過各種方式的使用讓系統(tǒng)變得非REST風(fēng)格。更糟的是，這使得人們更難在跟高層次上闡明REST的價(jià)值，因?yàn)椤癛EST風(fēng)格”的API在易用性和長期穩(wěn)定性方面與RPC這方面的性能并沒有明顯的差異。事實(shí)上，在某些情況下，某些性能會(huì)被認(rèn)為差得多，比如可用性方面。

對于客戶端來說，在REST風(fēng)格和非REST風(fēng)格的系統(tǒng)之間有兩個(gè)明顯的方式：URL結(jié)構(gòu)和文檔結(jié)構(gòu)。

正如我敢肯定的是你聽說過廣告令人厭倦，避免由客戶端構(gòu)造URL而是由服務(wù)端提供連接，這是REST風(fēng)格的超媒體的核心，這使得服務(wù)器真正擁有它的所有資源的名稱和位置。從而使其能夠獨(dú)立于它的客戶端進(jìn)行演變。但是，這僅僅當(dāng)客戶端使用服務(wù)端提供的連接時(shí)才有效，但更多地我比較愿意承認(rèn)，在客戶端真實(shí)的編程時(shí)他們會(huì)忽略服務(wù)端連接，而是用基于URL（多次硬編碼）的連接在之前的響應(yīng)體中加上各種數(shù)據(jù)。Swagger工具（甚至GraphQL）鼓勵(lì)這種使用它們的URI膜拜和占位符的模式。

客戶端和服務(wù)器端之間更加隱藏的耦合是涉及到如何領(lǐng)會(huì)每個(gè)請求和響應(yīng)的有效負(fù)載，在REST理想世界中，客戶端和服務(wù)器都綁定到一個(gè)標(biāo)準(zhǔn)的IANA注冊的上下文類型中，而且不會(huì)嘗試去理解任何超過以上范圍的事情，然而這不是我們生活的世界，它無疑不是我們希望生活的世界。業(yè)務(wù)系統(tǒng)通過他們的性質(zhì)、域特性等自然結(jié)果，即使是在相同的域中的每個(gè)系統(tǒng)彼此之間都有稍微不同的方言。無論是對還是錯(cuò)，這些差異是分化多次而作為競爭優(yōu)勢。此外，業(yè)務(wù)（和支持他的數(shù)據(jù)視圖）可以根據(jù)各種因素在響應(yīng)中快速改變。你可以多頻繁地支持標(biāo)準(zhǔn)媒體型的變化？得知它是以年計(jì)的你可能不會(huì)感到驚訝。

所以，如果一個(gè)客戶端和服務(wù)器不能依賴于綁定到一個(gè)標(biāo)準(zhǔn)的內(nèi)容類型去互相理解他們之間互相傳輸?shù)臄?shù)據(jù)的話，那他們穩(wěn)定性還可以依賴什么呢？恩，就像法定貨幣一樣，沒有什么。

好吧，這無可否認(rèn)具有一點(diǎn)戲劇性。但問題是系統(tǒng)的穩(wěn)定性確實(shí)在服務(wù)器和客戶端之間沒有雙關(guān)語義的用于理解數(shù)據(jù)的協(xié)議。這些規(guī)則必須在某處記錄起來然后在客戶端和服務(wù)器進(jìn)行編碼。規(guī)則可以用標(biāo)記或結(jié)構(gòu)化描述語言來記錄，并且他們可以直接在代碼中、在模式文檔中、在混合情況下進(jìn)行編碼，從模式文檔中生成代碼。對于所有的這些策略、工具、技術(shù)，提醒著存在一個(gè)“數(shù)據(jù)合同”（從我的WCF日子中借用此概念）代表客戶端和服務(wù)端之間互相作用從而使得系統(tǒng)很穩(wěn)定。任何數(shù)據(jù)合同的改變必然導(dǎo)致服務(wù)契約的改變。在更復(fù)雜的聯(lián)合服務(wù)中，其實(shí)還是有很多客戶端綁定的小數(shù)據(jù)合同。鑒于這一事實(shí)，WSDL和Swagger合并文檔模式到API程序描述文檔可能是正確的，將模式作為參數(shù)的類型（盡管我還是不同意這些大體上的策略）。

當(dāng)談及REST時(shí)，人們?nèi)绾螛?gòu)建客戶端真的是IMO的核心問題。在實(shí)踐中，REST風(fēng)格系統(tǒng)的前提是具有通用的客戶端，對于我們正在做的系統(tǒng)這樣做可能是不切實(shí)際的，市面上為什么只有這么少數(shù)量的瀏覽器的原因是，構(gòu)建瀏覽器是很難的。然而，這是因?yàn)闃?biāo)準(zhǔn)內(nèi)容類型的復(fù)雜性，比如HTML和協(xié)議、HTTP和DNS。它可以盡力基于潛在用戶而被調(diào)整的。就像對于業(yè)務(wù)系統(tǒng)，甚至是一個(gè)很龐大的系統(tǒng)，它更加難以調(diào)整類似的。尤其是當(dāng)需要?jiǎng)?chuàng)建（并獲得成功，更廣泛的行業(yè)支持）一個(gè)類似于HTML的標(biāo)準(zhǔn)內(nèi)容類型時(shí)。

所以，當(dāng)我們討論API時(shí)，也許現(xiàn)在是時(shí)候要理智真誠地放棄使用“REST”術(shù)語了。這將可以讓我們停止圍繞著他們是否是真正的REST風(fēng)格上越包越多，同時(shí)使我們能不覺得有必要拿出像“務(wù)實(shí)REST”條款。或許我們應(yīng)該著眼于建設(shè)可用的Web API。對我們用戶來說，可用性是重點(diǎn)。