RPC、REST API深入理解
一：RPC
RPC 即遠端過程呼叫（Remote Procedure Call Protocol，簡稱RPC），像呼叫本地服務(方法)一樣呼叫伺服器的服務(方法)。
通常的實現有 XML-RPC , JSON-RPC , 通訊方式基本相同, 所不同的只是傳輸資料的格式.
RPC是分散式架構的核心，按響應方式分如下兩種：
同步呼叫：客戶端呼叫服務方方法，等待直到服務方返回結果或者超時，再繼續自己的操作
非同步呼叫：客戶端把訊息傳送給中介軟體，不再等待服務端返回，直接繼續自己的操作。
同步呼叫的實現方式有WebService和RMI。
Web Service提供的服務是基於web容器的，底層使用http協議，因而適合不同語言異構系統間的呼叫。
RMI實際上是Java語言的RPC實現，允許方法返回 Java 物件以及基本資料型別，適合用於JAVA語言構建的不同系統間的呼叫。
非同步呼叫的JAVA實現版就是JMS(Java Message Service)，目前開源的的JMS中介軟體有Apache社群的ActiveMQ、Kafka訊息中介軟體，另外有阿里的RocketMQ。
RPC架構裡包含如下4個元件:
1、 客戶端(Client)：服務呼叫方
2、 客戶端存根(Client Stub)：存放服務端地址資訊，將客戶端的請求引數打包成網路訊息，再通過網路傳送給服務方
3、 服務端存根(Server Stub)：接受客戶端傳送過來的訊息並解包，再呼叫本地服務
4、服務端(Server)：真正的服務提供者。
具體實現步驟：
1、 服務呼叫方（client）(客戶端)以本地呼叫方式呼叫服務；
2、 client stub接收到呼叫後負責將方法、引數等組裝成能夠進行網路傳輸的訊息體；在Java裡就是序列化的過程
3、 client stub找到服務地址，並將訊息通過網路傳送到服務端；
4、 server stub收到訊息後進行解碼,在Java裡就是反序列化的過程；
5、 server stub根據解碼結果呼叫本地的服務；
6、 本地服務執行處理邏輯；
7、 本地服務將結果返回給server stub；
8、 server stub將返回結果打包成訊息，Java裡的序列化；
9、 server stub將打包後的訊息通過網路併發送至消費方
10、 client stub接收到訊息，並進行解碼, Java裡的反序列化；
11、 服務呼叫方（client）得到最終結果。
RPC框架的目標就是把2-10步封裝起來，把呼叫、編碼/解碼的過程封裝起來，讓使用者像呼叫本地服務一樣的呼叫遠端服務。
要做到對客戶端（呼叫方）透明化服務， RPC框架需要考慮解決如下問題：
1、通訊問題 : 主要是通過在客戶端和伺服器之間建立TCP連線，遠端過程呼叫的所有交換的資料都在這個連線裡傳輸。連線可以是按需連線，呼叫結束後就斷掉，也可以是長連線，多個遠端過程呼叫共享同一個連線。
2、定址問題 ： A伺服器上的應用怎麼告訴底層的RPC框架，如何連線到B伺服器（如主機或IP地址）以及特定的埠，方法的名稱是什麼，這樣才能完成呼叫。比如基於Web服務協議棧的RPC，就要提供一個endpoint URI，或者是從UDDI服務上查詢。如果是RMI呼叫的話，還需要一個RMI Registry來註冊服務的地址。
3、序列化與反序列化 ： 當A伺服器上的應用發起遠端過程呼叫時，方法的引數需要通過底層的網路協議如TCP傳遞到B伺服器，由於網路協議是基於二進位制的，記憶體中的引數的值要序列化成二進位制的形式，也就是序列化（Serialize）或編組（marshal），通過定址和傳輸將序列化的二進位制傳送給B伺服器。
同理，B伺服器接收引數要將引數反序列化。B伺服器應用呼叫自己的方法處理後返回的結果也要序列化給A伺服器，A伺服器接收也要經過反序列化的過程。
二：REST
REST即表述性狀態傳遞（Representational State Transfer，簡稱REST），是一種軟體架構風格。
REST通過HTTP協議定義的通用動詞方法(GET、PUT、DELETE、POST) ，以URI對網路資源進行唯一標識，響應端根據請求端的不同需求，通過無狀態通訊，對其請求的資源進行表述。
Rest架構的主要原則：
1. 網路上的所有事物都被抽象為資源
2. 每個資源都有一個唯一的資源識別符號
3. 同一個資源具有多種表現形式(xml,json等)
4. 對資源的各種操作不會改變資源識別符號
5. 所有的操作都是無狀態的
其中表述性狀態，是指(在某個瞬間狀態的)資源資料的快照，包括資源資料的內容、表述格式(XML、JSON)等資訊。
其中無狀態通訊，是指服務端(響應端)不儲存任何與特定HTTP請求相關的資源，應用狀態必須由請求方在請求過程中提供。
要求在網路通訊過程中，任意一個Web請求必須與其他請求隔離，當請求端提出請求時，請求本身包含了響應端為響應這一請求所需的全部資訊。
REST使用HTTP+URI+XML /JSON 的技術來實現，其API要求的架構風格：HTTP協議和URI用於統一介面和定位資源，文字、二進位制流、XML、JSON等格式用來作為資源的表述。
舉例：
在Restful之前的操作： 請求的地址對應具體的業務操作
http://127.0.0.1/user/query/1 GET 根據使用者id查詢使用者資料
http://127.0.0.1/user/save POST 新增使用者
http://127.0.0.1/user/update POST 修改使用者資訊
http://127.0.0.1/user/delete GET/POST 刪除使用者資訊
RESTful用法： 請求
http://127.0.0.1/user/1 GET 根據使用者id查詢使用者資料
http://127.0.0.1/user POST 新增使用者
http://127.0.0.1/user PUT 修改使用者資訊
http://127.0.0.1/user DELETE 刪除使用者資訊
RESTful風格的體現，在你使用了get請求，就是查詢；使用post請求,就是新增的請求；使用put請求，就是修改的請求；使用delete請求，就是刪除的請求。
這樣做就完全沒有必要對crud做具體的描述。
滿足REST約束條件和原則的架構，就被稱為是RESTful架構。就像URL都是URI(統一資源標識)的表現形式一樣，RESTful是符合REST原則的表現形式。
區別
使用RPC遠端服務呼叫方式與傳統http介面直接呼叫方式的差別在於：
從使用方面看，Http介面只關注服務提供方（服務端），對於客戶端怎麼呼叫，呼叫方式怎樣並不關心，通常情況下，客戶端使用Http方式進行呼叫時，只要將內容進行傳輸即可，這樣客戶端在使用時，需要更關注網路方面的傳輸，比較不適用與業務方面的開發；而RPC服務則需要客戶端介面與服務端保持一致，服務端提供一個方法，客戶端通過介面直接發起呼叫，業務開發人員僅需要關注業務方法的呼叫即可，不再關注網路傳輸的細節，在開發上更為高效。
從效能角度看，使用Http時，Http本身提供了豐富的狀態功能與擴充套件功能，但也正由於Http提供的功能過多，導致在網路傳輸時，需要攜帶的資訊更多，從效能角度上講，較為低效。而RPC服務網路傳輸上僅傳輸與業務內容相關的資料，傳輸資料更小，效能更高。
從運維角度看，使用Http介面時，常常使用一個前端代理，來進行Http轉發代理請求的操作，需要進行擴容時，則需要去修改代理伺服器的配置，較為繁瑣，也容易出錯。而使用RPC方式的微服務，則只要增加一個服務節點即可，註冊中心可自動感知到節點的變化，通知呼叫客戶端進行負載的動態控制，更為智慧，省去運維的
從使用方面看
從使用方面看，Http介面只關注服務提供方（服務端），對於客戶端怎麼呼叫，呼叫方式怎樣並不關心，通常情況下，客戶端使用Http方式進行呼叫時，只要將內容進行傳輸即可，這樣客戶端在使用時，需要更關注網路方面的傳輸，比較不適用與業務方面的開發；（restful是服務端把方法寫好，客戶端通過http方式呼叫，直接定位到方法上面去。）
而RPC服務則需要客戶端介面與服務端保持一致，服務端提供一個方法，客戶端通過介面直接發起呼叫，業務開發人員僅需要關注業務方法的呼叫即可，不再關注網路傳輸的細節，在開發上更為高效。（PRC是服務端提供好方法給客戶端呼叫。定位到類，然後通過類去呼叫方法。）
總結
RPC：所謂的遠端過程呼叫 (面向方法)
SOA：所謂的面向服務的架構(面向訊息)
REST：所謂的 Representational state transfer (面向資源)
RPC 即遠端過程呼叫, 很簡單的概念, 像呼叫本地服務(方法)一樣呼叫伺服器的服務(方法).
通常的實現有 XML-RPC , JSON-RPC , 通訊方式基本相同, 所不同的只是傳輸資料的格式.
REST 的三個要素是 唯一的資源標識, 簡單的方法 (此處的方法是個抽象的概念),一定的表達方式. 重要的特性：無狀態