原文：There is No REST API ? ?
譯者：杰微刊兼職翻譯汪建 ? ? ?
作者：Howard Dierking
最近我花了一些時間和我的團隊從API的角度來聊了REST的話題义桂，同樣也討論了如何利用諸如違反了REST的最重要原則的Swagger技術(shù)去創(chuàng)建API牧挣。正如我在討論中說的爷辱，那就是REST風(fēng)格不是用來描述API宇挫。REST描述了整個系統(tǒng)的架構(gòu)特性役首，用于描述此該系統(tǒng)包含了所有哪些不同組成的部分。它嘗試基于組件對系統(tǒng)提出系統(tǒng)級別的要求笨枯，甚至是對系統(tǒng)不起作用的一層瘟滨。
“我們對于REST風(fēng)格最大的幫倒忙的行為之一就是我們在REST后面添加了API字眼！”
目前我見過幾個不同公司的處理場景为牍，這些公司在最純粹的定義上將一個服務(wù)搭建成REST風(fēng)格哼绑，客戶端通過各種方式的使用讓系統(tǒng)變得非REST風(fēng)格岩馍。更糟的是，這使得人們更難在跟高層次上闡明REST的價值抖韩，因為“REST風(fēng)格”的API在易用性和長期穩(wěn)定性方面與RPC這方面的性能并沒有明顯的差異蛀恩。事實上，在某些情況下茂浮，某些性能會被認(rèn)為差得多双谆，比如可用性方面。
對于客戶端來說席揽，在REST風(fēng)格和非REST風(fēng)格的系統(tǒng)之間有兩個明顯的方式：URL結(jié)構(gòu)和文檔結(jié)構(gòu)顽馋。
正如我敢肯定的是你聽說過廣告令人厭倦，避免由客戶端構(gòu)造URL而是由服務(wù)端提供連接驹尼，這是REST風(fēng)格的超媒體的核心趣避，這使得服務(wù)器真正擁有它的所有資源的名稱和位置。從而使其能夠獨立于它的客戶端進行演變新翎。但是程帕，這僅僅當(dāng)客戶端使用服務(wù)端提供的連接時才有效，但更多地我比較愿意承認(rèn)地啰，在客戶端真實的編程時他們會忽略服務(wù)端連接愁拭，而是用基于URL（多次硬編碼）的連接在之前的響應(yīng)體中加上各種數(shù)據(jù)。Swagger工具（甚至GraphQL）鼓勵這種使用它們的URI膜拜和占位符的模式岭埠。
客戶端和服務(wù)器端之間更加隱藏的耦合是涉及到如何領(lǐng)會每個請求和響應(yīng)的有效負(fù)載，在REST理想世界中蔚鸥，客戶端和服務(wù)器都綁定到一個標(biāo)準(zhǔn)的IANA注冊的上下文類型中，而且不會嘗試去理解任何超過以上范圍的事情止喷，然而這不是我們生活的世界，它無疑不是我們希望生活的世界弹谁。業(yè)務(wù)系統(tǒng)通過他們的性質(zhì)乾巧、域特性等自然結(jié)果预愤，即使是在相同的域中的每個系統(tǒng)彼此之間都有稍微不同的方言。無論是對還是錯植康，這些差異是分化多次而作為競爭優(yōu)勢。此外销睁，業(yè)務(wù)（和支持他的數(shù)據(jù)視圖）可以根據(jù)各種因素在響應(yīng)中快速改變泳秀。你可以多頻繁地支持標(biāo)準(zhǔn)媒體型的變化？得知它是以年計的你可能不會感到驚訝嗜傅。
所以，如果一個客戶端和服務(wù)器不能依賴于綁定到一個標(biāo)準(zhǔn)的內(nèi)容類型去互相理解他們之間互相傳輸?shù)臄?shù)據(jù)的話吕嘀，那他們穩(wěn)定性還可以依賴什么呢违寞？恩偶房，就像法定貨幣一樣，沒有什么棕洋。
好吧挡闰，這無可否認(rèn)具有一點戲劇性。但問題是系統(tǒng)的穩(wěn)定性確實在服務(wù)器和客戶端之間沒有雙關(guān)語義的用于理解數(shù)據(jù)的協(xié)議掰盘。這些規(guī)則必須在某處記錄起來然后在客戶端和服務(wù)器進行編碼摄悯。規(guī)則可以用標(biāo)記或結(jié)構(gòu)化描述語言來記錄，并且他們可以直接在代碼中愧捕、在模式文檔中奢驯、在混合情況下進行編碼，從模式文檔中生成代碼次绘。對于所有的這些策略瘪阁、工具、技術(shù)邮偎，提醒著存在一個“數(shù)據(jù)合同”（從我的WCF日子中借用此概念）代表客戶端和服務(wù)端之間互相作用從而使得系統(tǒng)很穩(wěn)定管跺。任何數(shù)據(jù)合同的改變必然導(dǎo)致服務(wù)契約的改變。在更復(fù)雜的聯(lián)合服務(wù)中禾进，其實還是有很多客戶端綁定的小數(shù)據(jù)合同豁跑。鑒于這一事實，WSDL和Swagger合并文檔模式到API程序描述文檔可能是正確的命迈，將模式作為參數(shù)的類型（盡管我還是不同意這些大體上的策略）贩绕。
當(dāng)談及REST時火的，人們?nèi)绾螛?gòu)建客戶端真的是IMO的核心問題壶愤。在實踐中，REST風(fēng)格系統(tǒng)的前提是具有通用的客戶端馏鹤，對于我們正在做的系統(tǒng)這樣做可能是不切實際的征椒，市面上為什么只有這么少數(shù)量的瀏覽器的原因是，構(gòu)建瀏覽器是很難的湃累。然而勃救，這是因為標(biāo)準(zhǔn)內(nèi)容類型的復(fù)雜性碍讨，比如HTML和協(xié)議、HTTP和DNS蒙秒。它可以盡力基于潛在用戶而被調(diào)整的勃黍。就像對于業(yè)務(wù)系統(tǒng)，甚至是一個很龐大的系統(tǒng)晕讲，它更加難以調(diào)整類似的覆获。尤其是當(dāng)需要創(chuàng)建（并獲得成功，更廣泛的行業(yè)支持）一個類似于HTML的標(biāo)準(zhǔn)內(nèi)容類型時瓢省。
所以弄息，當(dāng)我們討論API時，也許現(xiàn)在是時候要理智真誠地放棄使用“REST”術(shù)語了勤婚。這將可以讓我們停止圍繞著他們是否是真正的REST風(fēng)格上越包越多摹量，同時使我們能不覺得有必要拿出像“務(wù)實REST”條款÷ǎ或許我們應(yīng)該著眼于建設(shè)可用的Web API缨称。對我們用戶來說，可用性是重點国章。
