業(yè)界正在逐漸承認(rèn)RESTful API優(yōu)于面向服務(wù)架構(gòu)。但是這對(duì)于架構(gòu)師和開(kāi)發(fā)人員而言到底意味著什么？Tom Nolle分享了他的想法。

在模塊化應(yīng)用世界里，最為持久的爭(zhēng)論莫過(guò)于面向服務(wù)架構(gòu)和表述性狀態(tài)轉(zhuǎn)移之爭(zhēng)了。本文探討這樣的爭(zhēng)論帶來(lái)了什么及其背后的原因。

SOA已經(jīng)被定性為連接組件和工作流的嚴(yán)格的且重量級(jí)的方案，REST則贏得了更多的贊譽(yù)。兩者的特征都是簡(jiǎn)化，但是要學(xué)習(xí)RESTful API設(shè)計(jì)，架構(gòu)師和開(kāi)發(fā)人員必須理解SOA和REST之間的差異，學(xué)習(xí)REST和云以及微服務(wù)一起的演進(jìn)，并且了解如何構(gòu)建穩(wěn)定且合規(guī)的RESTful工作流。

SOA廣義上指基于連接的組件化服務(wù)的應(yīng)用設(shè)計(jì)，基于這個(gè)定義，REST實(shí)際上是SOA的一種實(shí)現(xiàn)。實(shí)際API之爭(zhēng)是在簡(jiǎn)單對(duì)象訪問(wèn)協(xié)議（SOAP）及實(shí)現(xiàn)其Web服務(wù)標(biāo)準(zhǔn)和REST之間。這兩者有著本質(zhì)的不同：SOAP從用于擴(kuò)展網(wǎng)絡(luò)連接之上的模塊化編程的遠(yuǎn)地過(guò)程調(diào)用演進(jìn)而來(lái)，而REST從互聯(lián)網(wǎng)組件的“資源”角度而來(lái)。

使用SOAP，網(wǎng)絡(luò)連接的組件是模塊，也就是說(shuō)他們可以被看成帶有功能調(diào)用和參數(shù)的“過(guò)程”或者“類”。SOAP的目標(biāo)是使得過(guò)程能夠在遠(yuǎn)程工作，包括讓開(kāi)發(fā)人員找到過(guò)程，并且將其正確綁定到執(zhí)行上。在REST的世界里，組件代表請(qǐng)求訪問(wèn)的資源——一個(gè)內(nèi)部實(shí)現(xiàn)細(xì)節(jié)不透明的真正黑盒子。SOAP里不會(huì)假定遠(yuǎn)程組件是無(wú)狀態(tài)的。本地過(guò)程以及REST則會(huì)假定調(diào)用是無(wú)狀態(tài)的；在執(zhí)行之間RESTful服務(wù)不會(huì)駐留任何東西。

云計(jì)算和微服務(wù)幾乎已經(jīng)使得RESTful API成為了既定業(yè)界標(biāo)準(zhǔn)，因此對(duì)于開(kāi)發(fā)人員和架構(gòu)師而言需要重點(diǎn)理解REST。

正是REST的無(wú)狀態(tài)特征使其在云應(yīng)用里作用非凡。當(dāng)錯(cuò)誤發(fā)生時(shí)，無(wú)狀態(tài)組件可以隨意重新部署，也可以在負(fù)載改變時(shí)隨意伸縮。因?yàn)槿我庹?qǐng)求都可以發(fā)送到組件的任意實(shí)例上；不會(huì)有任何東西保存在另一個(gè)實(shí)例里，而需要下一次事務(wù)“記憶”住的。SOAP開(kāi)發(fā)也可以這么實(shí)現(xiàn)，但并不是必須的。

基于這個(gè)原因，Web場(chǎng)景下更喜歡使用REST，不過(guò)在云服務(wù)里RESTful模型也很有用，因?yàn)橥ㄟ^(guò)API綁定到某個(gè)服務(wù)一般而言就是控制URL解析的方式。如果一個(gè)應(yīng)用通過(guò)URL“知道”某個(gè)組件或者微服務(wù)，那么如果服務(wù)最初的實(shí)例出現(xiàn)故障，改變URL相關(guān)聯(lián)的IP地址就會(huì)讓請(qǐng)求路由到新的實(shí)例里。不需要其他額外的目錄管理。如果URL指向某個(gè)負(fù)載均衡器，那么使用簡(jiǎn)單的算法就可以分發(fā)工作，因?yàn)闆](méi)有哪個(gè)請(qǐng)求特別需要某個(gè)“記憶”了狀態(tài)的特定實(shí)例來(lái)處理。

云計(jì)算和微服務(wù)幾乎已經(jīng)使得RESTful API成為了既定業(yè)界標(biāo)準(zhǔn)，因此對(duì)于開(kāi)發(fā)人員和架構(gòu)師而言需要重點(diǎn)理解REST。這意味著在應(yīng)用里需要解決狀態(tài)控制的一致性，管理安全性，從而解耦合組件并且創(chuàng)建高效的服務(wù)目錄。

REST里有兩種管理狀態(tài)的方式——在RESTful調(diào)用里將狀態(tài)傳遞給服務(wù)，或者由服務(wù)的任意實(shí)例都可以訪問(wèn)的后臺(tái)數(shù)據(jù)庫(kù)來(lái)維護(hù)狀態(tài)。如果想要RESTful應(yīng)用像基于SOAP的應(yīng)用一樣合規(guī)，那么就需要采取一致的方案。除非訪問(wèn)后臺(tái)狀態(tài)數(shù)據(jù)庫(kù)的方案不現(xiàn)實(shí)，否則都應(yīng)該考慮優(yōu)先選擇后臺(tái)狀態(tài)管理?？蛻舳藸顟B(tài)控制在客戶端實(shí)例故障時(shí)會(huì)導(dǎo)致問(wèn)題。

保證安全性

REST的安全問(wèn)題很可怕，但是大多數(shù)情況下，這些安全問(wèn)題的假設(shè)都是應(yīng)用組件放置在開(kāi)放的互聯(lián)網(wǎng)或者VPN里。簡(jiǎn)單確定組件部署處的私有的RFC1918地址空間，可以大幅提高REST安全性。當(dāng)組件間大規(guī)模集成對(duì)于應(yīng)用而言必不可少時(shí)，這樣的方案就不適用了，那么就有必要使用安全連接，比如https。身份令牌也可以作為RESTful API數(shù)據(jù)包的一部分。

有很多REST目錄服務(wù)，ProgrammableWeb可能是其中最知名的服務(wù)，但是它們都關(guān)注于公開(kāi)暴露的API。Internet社區(qū)內(nèi)部關(guān)于私有RESTful API是否自相矛盾這個(gè)問(wèn)題上存在爭(zhēng)議，但是從實(shí)用的角度，大多數(shù)公司都需要使用私有API目錄，從而讓開(kāi)發(fā)人員可以訪問(wèn)其RESTful API。否則，肯定會(huì)影響到企業(yè)數(shù)據(jù)和合規(guī)需求。

如果你在考察RESTful API目錄工具，首先需要關(guān)注那些為微服務(wù)而設(shè)計(jì)的工具，因?yàn)檫@是云API領(lǐng)域的整體趨勢(shì)。核心需求是支持三層API——私有內(nèi)部或者甚至部門的API，“合作伙伴”或者社區(qū)API以及公開(kāi)API。不過(guò)要記住，如果可以在網(wǎng)絡(luò)地址空間里訪問(wèn)Web服務(wù)或者微服務(wù)，它就有可能被hack。即使API目錄有安全保障，也同時(shí)需要考慮恰當(dāng)?shù)牡刂房刂苹蛘吖ぷ髁骷用堋?/p>

REST和微服務(wù)使得組件整合更為容易，并且提供了云和虛擬化應(yīng)用大規(guī)模擴(kuò)展和彈性的可能性。通過(guò)解耦合SOAP引入的組件綁定規(guī)則來(lái)實(shí)現(xiàn)，那么應(yīng)用規(guī)劃師和開(kāi)發(fā)人員可以通過(guò)其他方式實(shí)現(xiàn)安全和合規(guī)支持。REST和微服務(wù)在業(yè)界快速得到大量支持，因此需要在你的應(yīng)用里準(zhǔn)備好使用它們。