RPC 與HTTP的相同點
兩種風格的API區別，總結一下其實非常簡單：
1，RPC面向過程，只發送 GET 和 POST 請求。GET用來查詢信息，其他情況下一律用POST。請求參數是動詞，直接描述動作本身。,
2，RESTful面向資源，使用 POST、DELETE、PUT、GET 請求，分別對應增、刪、改、查操作。請求參數是名詞，這個名詞就是“增刪改查”想要操作的對象。
前面提到，這樣對比RPC與REST並不完全准確，原因在於RPC不僅僅是一種API設計風格，它的概念比這要廣得多。PRC全稱是Remote Procedure Call，即遠程過程調用。我發送了一個RPC請求比如 POST /removeItem?itemId=456，實際上是調用了服務端的一個方法 removeItem(int itemId)。在我本地電腦上可以調用一個遠在服務端的方法，所以叫遠程過程調用。這個"遠"的概念也不一定是跨越網絡的，同一台主機的兩個進程之間相互交流也完全可以是RPC。
只要是遠程調用都可以叫RPC，和是不是通過http沒什么關系，REST就是一種常用的rpc。
當然rpc也有不通過http的，可以直接走socket，或者其他協議，在不同的場景甚至有優於http的性能表現，這個很正常。用http不是因為它性能好，而是因為它普適，隨便一個web容器就能跑起來你的應用。
對外開放給全世界的API推薦采用RESTful，是否嚴格按照規范是一個要權衡的問題。要綜合成本、穩定性、易用性、業務場景等等多種因素。
內部調用推薦采用RPC方式，當然不能一概而論，還要看具體的業務場景。
RPC 與HTTP的不同點
在HTTP和RPC的選擇上，可能有些人是迷惑的，主要是因為，有些RPC框架配置復雜，如果走HTTP也能完成同樣的功能，那么為什么要選擇RPC，而不是更容易上手的HTTP來實現了。
本文主要來闡述HTTP和RPC的異同，讓大家更容易根據自己的實際情況選擇更適合的方案。
傳輸協議
RPC，可以基於TCP協議，也可以基於HTTP協議
HTTP，基於HTTP協議（在TCP協議之上進行封裝）
傳輸效率
RPC，使用自定義的TCP協議，可以讓請求報文體積更小，或者使用HTTP2協議，也可以很好的減少報文的體積，提高傳輸效率
HTTP，如果是基於HTTP1.1的協議，請求中會包含很多無用的內容，如果是基於HTTP2.0，那么簡單的封裝以下是可以作為一個RPC來使用的，這時標准RPC框架更多的是服務治理
性能消耗，主要在於序列化和反序列化的耗時
RPC，可以基於thrift實現高效的二進制傳輸
HTTP，大部分是通過json來實現的，字節大小和序列化耗時都比thrift要更消耗性能
負載均衡
RPC，基本都自帶了負載均衡策略
HTTP，需要配置Nginx，HAProxy來實現
服務治理（下游服務新增，重啟，下線時如何不影響上游調用者）
RPC，能做到自動通知，不影響上游
HTTP，需要事先通知，修改Nginx/HAProxy配置
總結：
RPC主要用於公司內部的服務調用，性能消耗低，傳輸效率高，服務治理方便。HTTP主要用於對外的異構環境，瀏覽器接口調用，APP接口調用，第三方接口調用等。
既然兩種方式都可以實現遠程調用，我們該如何選擇呢？
- 速度來看，RPC要比http更快，雖然底層都是TCP，但是http協議的信息往往比較臃腫，不過可以采用gzip壓縮。
- 難度來看，RPC實現較為復雜，http相對比較簡單
- 靈活性來看，http更勝一籌，因為它不關心實現細節，跨平台、跨語言。
因此，兩者都有不同的使用場景：
- 如果對效率要求更高，並且開發過程使用統一的技術棧，那么用RPC還是不錯的。
- 如果需要更加靈活，跨語言、跨平台，顯然http更合適
微服務，更加強調的是獨立、自治、靈活。而RPC方式的限制較多，因此微服務框架中，一般都會采用基於Http的Rest風格服務，像在公司對內系統用hsf協議，對接外部系統用微服務，調用RestTemplate這個類