為什么有些面試官很喜歡問這個 Restful、SOAP、RPC、SOA 之間的區(qū)別，而回答的時候，總是回答的沒有那么的好，于是就想讓阿粉給她解答一下這個內(nèi)容，于是阿粉專門來寫一篇文章來進(jìn)行這個解答。

什么是 Restful

Restful(Representational State Transfer)是?種架構(gòu)設(shè)計?格，提供了設(shè)計原則和約束條件，?不是架構(gòu)，?滿?這些約束條件和原則的 應(yīng)?程序或設(shè)計就是 Restful架構(gòu)或服務(wù)。

也就是說，他并不是說是一種架構(gòu)，而是一種設(shè)計上的風(fēng)格，就類似那種約定俗成的，阿粉最早知道這個 Restful 的時候，還是之前看過大神阮一峰的博客才學(xué)習(xí)到的。

其實想要理解Restful，那么你得先知道 Restful 的主要設(shè)計原則，那么 Restful 的主要設(shè)計原則都有哪些？

• 資源與URI
• 統(tǒng)?資源接?(HTTP?法如GET，PUT和POST)
• 資源的表述
• 資源的鏈接
• 狀態(tài)的轉(zhuǎn)移

實際上，REST全稱是表述性狀態(tài)轉(zhuǎn)移，那究竟指的是什么的表述? 其實指的就是資源。

**資源與URI

這時候就會有讀者問，那這個資源又是怎么定義的呢？

這個資源實際上就相當(dāng)于是一個抽象的概念，只要你這個事物，有被引用到的地方，那么他就可以定義成為一個資源，就比如我們的姓名，手機(jī)號，

• 警察落戶需要你的姓名
• 辦理某些會員卡需要你的姓名
• 你在辦理會員卡的時候，需要綁定一下手機(jī)號

也就是說，你的姓名和你的手機(jī)號，都有被引用得到的地方，那么他就可以稱之為資源。

那么什么又是URI呢？

要讓一個資源可以被識別，需要有個唯一標(biāo)識，在Web中這個唯一標(biāo)識就是URI(Uniform Resource Identifier)。

這個對開發(fā)來說就很容易理解了，URI 就是地址

• https://www.baidu.com/
• https://www.taobao.com/
• https://www.jd.com/

統(tǒng)?資源接?

那么什么是統(tǒng)一資源接口呢？

這就又得說到 Restful 架構(gòu)設(shè)計?格的定義上來了，遵循的原則還是，遵循統(tǒng)一接口原則，統(tǒng)一接口包含了一組受限的預(yù)定義的操作，不論什么樣的資源，都是通過使用相同的接口進(jìn)行資源的訪問。接口應(yīng)該使用標(biāo)準(zhǔn)的HTTP方法如GET，PUT和POST，并遵循這些方法的語義。

如果這么說，大家我相信那是明白的非常透徹的，畢竟你看，你寫接口的時候，直接來的不就是

@PostMapping(value = "/order/create", produces = MediaType.APPLICATION_JSON_VALUE)
public JsonObjcet createOrder(){
      .....
}

是不是都是這么寫的，實際上他就是一種 Restful 風(fēng)格的。

至于請求的狀態(tài)碼，阿粉就不再多說什么了，相信只要是看阿粉文章的，百分之百也都明白狀態(tài)碼一般對應(yīng)什么樣子的含義。

資源的表述

那么什么是資源的描述呢？

這個理解就比較簡單了，為什么這么說，你可以這樣理解，只關(guān)心你給的返回內(nèi)容，不關(guān)心你內(nèi)部實現(xiàn)。

換成比較官方的語言就是：

客戶端獲取的只是資源的表述而已。資源在外界的具體呈現(xiàn)，可以有多種表述(或稱為表現(xiàn)、表示)形式，在客戶端和服務(wù)端之間傳送的也是資源的表述，而不是資源本身。例如文本資源可以采用html、xml、json等格式，圖片可以使用PNG或JPG展現(xiàn)出來。

其實資源的描述阿粉覺得他就是數(shù)據(jù)展示，但是很多人也不是這么理解，畢竟每個人的理解都是不一樣的，也沒有什么標(biāo)準(zhǔn)答案，畢竟不是 1+1=2 的數(shù)學(xué)問題，不是么？

資源的鏈接

資源的鏈接，這個相對來說，也挺容易理解的，一般的，我們在項目里面，很多都是從一個鏈接去到另外一個鏈接，獲取我們的想要的資源信息，比如說，我們有一個活動，如果你想要獲取這個活動的最新詳情，那么就一定需要我們再去對這個資源進(jìn)行一個獲取，實際上如果簡單來說，就是對資源做了個CRUD。

狀態(tài)的轉(zhuǎn)移

實際上，我們在看某些頁面的時候，一直在默默的接受這個狀態(tài)轉(zhuǎn)移，比如，“下一頁”，因為這個 “下一頁” 就會表示，你從當(dāng)前的這個狀態(tài)，轉(zhuǎn)到下一個未知的狀態(tài)， 這實際上就是狀態(tài)的轉(zhuǎn)移。

**什么是SOAP

相對來說 SOAP 就不如 Restful 那么復(fù)雜了，需要你理解的東西沒那么多了。

簡單對象訪問協(xié)議是?種數(shù)據(jù)交換協(xié)議規(guī)范，是?種輕量的、簡單的、基于XML的協(xié)議的規(guī)范。

SOAP協(xié)議和HTTP協(xié)議?樣，都是底層的通信協(xié)議，只是請求包的格式不同?已，SOAP包是XML格式的。SOAP的消息是基于xml并封裝成了符合http協(xié)議，因此，它符合任何路由器、 防?墻或代理服務(wù)器的要求。

SOAP可以使?任何語?來完成，只要發(fā)送正確的soap請求即可，基于soap的服務(wù)可以在任何平臺?需 修改即可正常使?

**什么是RPC

RPC就是從?臺機(jī)器（客戶端）上通過參數(shù)傳遞的?式調(diào)?另?臺機(jī)器（服務(wù)器）上的?個函數(shù)或?法 （可以統(tǒng)稱為服務(wù)）并得到返回的結(jié)果。

RPC 會隱藏底層的通訊細(xì)節(jié)（不需要直接處理Socket通訊或Http通訊）

RPC 是?個請求響應(yīng)模型。客戶端發(fā)起請求，服務(wù)器返回響應(yīng)（類似于Http的?作?式）

RPC 在使?形式上像調(diào)?本地函數(shù)（或?法）?樣去調(diào)?遠(yuǎn)程的函數(shù)（或?法）。

其實說到RPC，這個屬實是面試的時候，經(jīng)常會被問到的一個地方，為什么這么說，因為有很多很多的框架，都是用的 RPC 。

比如已經(jīng)進(jìn)入 Apache 孵化器的 Dubbo ,還有還有SpringCloud框架，微服務(wù)全家桶。這都是比較出名的用 RPC 的框架，但是很多人就會說，別瞎扯了，人家SpringCloud 明明是用的 http ，確實，也沒啥錯誤。

spring cloud是基于spring boot 的，spring boot 實現(xiàn)的是http協(xié)議的rpc，算是rpc的?個?集。

所以阿粉在這里也把 SpringCloud 給算進(jìn)來了。

什么是SOA

說到SOA，英文全稱是（（Service-Oriented Architecture），翻譯成中文就是?向服務(wù)的架構(gòu)。

這就是最經(jīng)典的微服務(wù)架構(gòu)了，微服務(wù)架構(gòu)就是從 SOA 進(jìn)化的結(jié)果。

兩者說到底都是對外提供接?的?種架構(gòu)設(shè)計?式,隨著互聯(lián)?的發(fā)展， 復(fù)雜的平臺、業(yè)務(wù)的出現(xiàn)，導(dǎo)致SOA架構(gòu)向更細(xì)粒度、更通過化程度發(fā)展，就成了所謂的微服務(wù)了。

通俗點來講，SOA提倡將不同應(yīng)?程序的業(yè)務(wù)功能封裝成“服務(wù)”并宿主起來，通常以接?和契約的形式暴 露并提供給外界應(yīng)?訪問（通過交換消息），達(dá)到不同系統(tǒng)可重?的?的。

SOA是?個組件模型，它能將不同的服務(wù)通過定義良好的接?和契約聯(lián)系起來。服務(wù)是SOA的基?。

所以后面就出現(xiàn)了這個微服務(wù)了。

今天阿粉要說的內(nèi)容，就這些了，你理解了么？

文章參考

• 《百度百科》 
• 《RESTful Web Services》