前言

這兩天在和同學(xué)談到RPC、RESTful時候發(fā)現(xiàn)自己對這兩者并不是很理解，于是查閱了網(wǎng)上相關(guān)資料加上自己的理解寫下本篇文章以加深印象，由于本人水平有限，若對這兩者的理解有不妥之處望指出。

什么是REST和RESTful

在認(rèn)識RESTful之前，我們先科普一下REST。

REST

REST即Representational State Transfer的縮寫，是基于HTTP協(xié)議之上的一組約束和屬性，翻譯過來是表現(xiàn)層狀態(tài)轉(zhuǎn)移。REST是一種設(shè)計風(fēng)格（并非一種標(biāo)準(zhǔn)），描述的是在網(wǎng)絡(luò)中Client和Server的一種交互形式，目的是便于不同的軟件/程序在網(wǎng)絡(luò)中互相傳遞消息。按照我的理解：我們通過URI定位到服務(wù)器上的資源（例如文本、圖片、服務(wù)），然后對資源進(jìn)行某種操作（CRUD）并且返回足夠的信息描述服務(wù)器的狀態(tài)（比如：狀態(tài)碼）讓客戶端知道如何處理，資源傳遞給客戶端并且以某種形式表現(xiàn)（比如JSON、HTML、XML、PNG等）出來，而REST則是將URI的命名風(fēng)格、對資源操作的實現(xiàn)方式、操作之后返回什么信息和資源以哪種形式表現(xiàn)出來等總結(jié)成了一種設(shè)計風(fēng)格，讓大家都使用這種設(shè)計風(fēng)格去實現(xiàn)這些設(shè)計，當(dāng)然REST的設(shè)計風(fēng)格不止我指出的這幾個，只是這幾個是要點。 REST設(shè)計的風(fēng)格遵循以下幾點：

利用HTTP方法讓接口統(tǒng)一化 REST充分利用HTTP自身的GET、POST、PUT、DELETE的方法實現(xiàn)接口的統(tǒng)一化，比如對同一個資源進(jìn)行CRUD操作時：

GET /posts 獲取文章 GET /getPosts 獲取文章 POST /posts 發(fā)布文章 GET /addPosts 發(fā)布文章 PUT /posts 修改文章 GET /editPosts 修改文章 DELETE /posts 刪除文章 GET /deletePosts 刪除文章 復(fù)制代碼

上面的設(shè)計中，左邊的是符合REST設(shè)計風(fēng)格的，右邊的是不符合REST設(shè)計風(fēng)格的。URI只需將資源準(zhǔn)確無誤的暴露出來就可以，而不需要加上動作詞，而動作則體現(xiàn)在HTTP的GET、POST、PUT、DELETE方法中，其中URI還推薦使用復(fù)數(shù)。

利用HTTP狀態(tài)碼返回狀態(tài)信息 下面舉例幾個HTTP Status Code和表示的什么：

Status Code: 200 OK Status Code: 400 Bed Request Status Code: 404 Not Found Status Code: 500 Internal Server Error 復(fù)制代碼

其中2XX的狀態(tài)碼表示請求已成功被服務(wù)器已接收、理解、并接受 3XX的狀態(tài)碼表示重定向 4XX的狀態(tài)碼表示客戶端錯誤 5XX的狀態(tài)碼表示服務(wù)器錯誤

利用HTTP報頭告知對方如何處理本次請求（相應(yīng)） HTTP報頭是描述客戶端與服務(wù)器之間的請求或者響應(yīng)應(yīng)該如何處理本次請求的，比如該用什么表現(xiàn)形式。

Authorization 認(rèn)證報頭 Cache-Control 緩存報頭 Cnotent-Type 消息體類型報頭 復(fù)制代碼

無狀態(tài) REST設(shè)計風(fēng)格要求Server無狀態(tài)，無狀態(tài)并不等于不保存用戶的狀態(tài)，而是指服務(wù)器不保存請求狀態(tài)（會話信息），客戶端必須每次都帶上自己的狀態(tài)去請求服務(wù)器，如果確實要維持用戶的狀態(tài)，也應(yīng)由客戶端負(fù)責(zé)，例如：在服務(wù)端上通過Cookie保存Token，之后的請求中都帶上Token，而這個Token就保存有了用戶的狀態(tài)（如登錄信息）。這里需要注意的是：

• 通過Session保存狀態(tài)不是REST設(shè)計風(fēng)格，因為Session是將狀態(tài)信息（用戶信息、過期時間等）保存在了服務(wù)器上，比如用戶登錄成功后，會將Session信息保存在服務(wù)器，然后返回個SessionID給客戶端并且將SessionID保存在Cookies中,之后的請求客戶端都會通過Cookies傳遞SessionID給服務(wù)器，服務(wù)器根據(jù)客戶端傳來的SessionID去匹配之前保存的Session狀態(tài)信息，所以這個狀態(tài)是保存在服務(wù)器上的，是靠服務(wù)器維持的，所以不是REST設(shè)計風(fēng)格。
• 通過Token保存狀態(tài)是REST設(shè)計風(fēng)格，因為狀態(tài)信息（用戶信息、過期時間等）都是保存在Token中，而Token又是保存在客戶端中（如Cookies），比如用戶登錄成功后，服務(wù)器會返回一個Token（包含了用戶信息、過期時間等）給服務(wù)端，服務(wù)端將Token保存在Cookies中，之后的請求客戶端都會取出Token放到Request Headers中傳給服務(wù)器，服務(wù)器驗證Token的有效性即可。

看到這里是不是能理解**狀態(tài)轉(zhuǎn)移*這個詞了？就是狀態(tài)通過客戶端來轉(zhuǎn)移。

簡單的來說就是狀態(tài)信息保存在服務(wù)器的就是有狀態(tài)的，而狀態(tài)信息保存在客戶端的就是無狀態(tài)的。通過REST的無狀態(tài)原則恰好有利于實現(xiàn)負(fù)載均衡，在分布式的Web系統(tǒng)上，有多個可用的服務(wù)器，每個服務(wù)器都可以處理客戶端發(fā)來的請求，及時有一臺服務(wù)器宕機(jī)，無狀態(tài)的請求可以交給別的服務(wù)器處理，這是有狀態(tài)的請求所做不到的。

什么是RESTful

理解完REST那我們就很容易理解RESTful了，RESTful即實現(xiàn)REST設(shè)計風(fēng)格的一種架構(gòu)，如RESTful API（REST設(shè)計風(fēng)格的API）

什么是RPC

RPC就是Remote Procedure Call的簡稱，翻譯成中文就是遠(yuǎn)程過程調(diào)用，什么是遠(yuǎn)程過程調(diào)用？舉個例子：有兩臺服務(wù)器A、B，一個應(yīng)用部署在A服務(wù)器上，另一個應(yīng)用部署在B服務(wù)器上，A服務(wù)器上的應(yīng)用想要調(diào)用B服務(wù)器上應(yīng)用所提供的方法、函數(shù)，那么這個調(diào)用過程就需要網(wǎng)絡(luò)來支撐，整個調(diào)用過程可以用下圖表示。

RPC分類

其中RPC分為兩種：

同步調(diào)用 在上面舉的例子中，A服務(wù)器的應(yīng)用調(diào)用B服務(wù)器上應(yīng)用的方法、函數(shù)后，A服務(wù)器的應(yīng)用會處在阻塞狀態(tài)，只有等到B服務(wù)器上的應(yīng)用通過網(wǎng)絡(luò)返回結(jié)果后，A服務(wù)器的應(yīng)用才會繼續(xù)往下執(zhí)行。

異步調(diào)用 在上面舉的例子中，A服務(wù)器的應(yīng)用調(diào)用B服務(wù)器上應(yīng)用的方法、函數(shù)后，A服務(wù)器的應(yīng)用并不會進(jìn)入阻塞狀態(tài)等待結(jié)果的返回，可以通過回調(diào)通知等方式獲得返回的結(jié)果。

RPC的網(wǎng)絡(luò)通信問題

我們知道在RPC調(diào)用的時候需要網(wǎng)絡(luò)來支撐，那么以何種方式來實現(xiàn)通信呢。

HTTP協(xié)議 A服務(wù)器的應(yīng)用可以通過HTTP將數(shù)據(jù)傳輸?shù)紹服務(wù)器，B服務(wù)器接收到數(shù)據(jù)后執(zhí)行數(shù)據(jù)中調(diào)用的指定方法、函數(shù)，例如谷歌的gRPC就是在HTTP上進(jìn)行數(shù)據(jù)傳輸?shù)摹５怯捎贖TTP報頭中有太多不需要的信息造成帶寬的浪費，所以很多人都是用比HTTP傳輸效率高的TCP、UDP進(jìn)行數(shù)據(jù)傳輸。

TCP、UDP 例如著名的Netty就是基于TCP、UDP上進(jìn)行傳輸?shù)?#xff0c;當(dāng)然你也可以不使用框架，自己編寫Socket實現(xiàn)網(wǎng)絡(luò)數(shù)據(jù)傳輸。

RESTful API和RPC

RESTful API和RPC區(qū)別和關(guān)系

在我理解中，RESTful API和RPC是兩種完全不同概念的東西，是沒法放在一起比較的，如果硬要將它倆比較，我認(rèn)為RESTful是RPC的一種實現(xiàn)，即RPC包括RESTful API，但RPC不等于RESTful API。

• RPC：我認(rèn)為RPC是一種為實現(xiàn)遠(yuǎn)程調(diào)用而提出一種思想，至于你用什么方式去達(dá)到目的都可以（例如：用什么網(wǎng)絡(luò)協(xié)議來傳輸數(shù)據(jù)看自己的選擇）。
• RESTful API：符合REST設(shè)計風(fēng)格的一種接口架構(gòu)，它也是通過網(wǎng)絡(luò)進(jìn)行的遠(yuǎn)程調(diào)用，但是遠(yuǎn)程調(diào)用僅限于HTTP。

RESTful API和RPC用途

既然RESTful API和RPC都可以實現(xiàn)遠(yuǎn)程調(diào)用，那我們應(yīng)該在這兩者之中如何抉擇呢？

• RESTful API：主要用在為第三方提供調(diào)用自家系統(tǒng)的一種途徑。
• RPC：主要用在自家系統(tǒng)之間的互相調(diào)用，即實現(xiàn)系統(tǒng)的分布式。

總結(jié)

在這里我僅是以我掌握的知識給大家介紹RPC和RESTful，給初學(xué)者大概了解一下RPC和RESTful，若文中有不妥的地方希望大家指出。

轉(zhuǎn)自：ddnd.cn/2018/12/19/…

轉(zhuǎn)載于:https://juejin.im/post/5c19f94fe51d45069e53c03c

總結(jié)

以上是生活随笔為你收集整理的【技术杂谈】RPC和RESTful API入门篇的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。