前言

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

什么是REST和RESTful

在認識RESTful之前，我們先科普一下REST。

REST

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

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

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

上面的設計中，左邊的是符合REST設計風格的，右邊的是不符合REST設計風格的。URI只需將資源準確無誤的暴露出來就可以，而不需要加上動作詞，而動作則體現(xiàn)在HTTP的GET、POST、PUT、DELETE方法中，其中URI還推薦使用復數(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 復制代碼

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

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

Authorization 認證報頭 Cache-Control 緩存報頭 Cnotent-Type 消息體類型報頭 復制代碼

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

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

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

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

什么是RESTful

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

什么是RPC

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

RPC分類

其中RPC分為兩種：

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

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

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

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

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

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

RESTful API和RPC

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

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

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

RESTful API和RPC用途

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

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

總結

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

轉自：ddnd.cn/2018/12/19/…

轉載于:https://juejin.im/post/5c19f94fe51d45069e53c03c

總結

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

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