TA貢獻1830條經驗 獲得超9個贊
HTTP是通信協議，RPC是一種開發方式，他可以基于HTTP協議（比如gRPC)，也可以基于其他協議，比如更基礎的TCP
通信協議的選擇只是RPC實現中的一小部分，更重要的一部分是編碼協議。比如json/xml屬于文本編碼，還有二進制字節編碼，比如protoful，thrift。http對比tcp，最詬病的就是多余的頭信息，而且還是使用的文本編碼，造成整個數據包體積過大。不過據說http2改進很多，修改為二進制編碼了，還支持多路復用，gRPC就是基于http2實現的。
至于restful，其實他本身是一套將資源對象化的設計標準，不過目前都作為技術實現再用，本身又分為嚴格的和非嚴格的。從目前上來說restful接口可以認為是一種基于http使用json編碼的RPC實現，但還是本身restful是設計規范，更多的是約束資源的訪問獲取手段，不應當用于復雜的函數調用。
最后前后端，目前javascript也有json-RPC，ajax-RPC一類的更專注于函數調用的RPC實現，可以基于HTTP，也可以基于websocket，如果目的是函數調用，你可以試用一下，會比使用restful舒服很多。
TA貢獻1946條經驗 獲得超4個贊
正在做的項目使用的是icegrid，最大的用處是將列如redis服務，es搜索服務，業務服務等等都是單獨獨立出來，解決程序間的耦合問題，只提供service層接口。所以我理解的rpc框架就是客服端與服務端的交互，而客戶端亦可稱為其他程序的服務端。因此感覺在web項目使用rpc框架并不是很適用。
TA貢獻1829條經驗 獲得超7個贊
我的觀點是http與RPC在實現上沒有本質的區別，但是，http和RPC的設計目標是不一樣的。
在實際中：
TA貢獻2021條經驗 獲得超8個贊
rpc是沒有post和get之分的.
你可以把多個rpc服務想象成一個很大的項目中的某些方法，比如 user相關方法，支付相關方法，rpc 只是把他們拆分開來而已，rpc直接可以互相調用，通過客戶端調用即可。
當然前端也可以直接調用rpc，但是這樣不好的一點就是各個端都不統一，可能做出來的東西bug比較多。
如果提供http服務，后端可以在http中調用相關rpc，把需要的聚合在一起，返回給前端，這樣就比較統一了。
TA貢獻2051條經驗 獲得超10個贊
看問題要看到問題的本質，為什么要有RPC，如果沒有RPC 會有什么樣的困難，其實你可以這么理解，RPC 是基于http or TCP 協議之上實現的一種封裝。 比如在 APP 開發中，以前沒有GRPC 我們需要手動去發送請求，解包，然后再使用，但是如果我們在APP 開發中如果用GRPC 協議，那么我們只管調用都可以啦。那么從開發角度來說，GRPC 是不是功能上幫你做啦一層封裝。后端也一樣，如果沒有GRPC 我們需要手動的去調用http 或者 tcp ，
TA貢獻1719條經驗 獲得超6個贊
RPC遠程過程調用，本質上來說并不是一種協議，而是一種架構方法。將業務進行分布式部署，但是邏輯上調用起來好像“調用本地方法”一樣。
http只是RPC的一種手段，thrift,grpc都是如此，不過后兩個是直接基于TCP協議開發的私有協議棧，傳輸效率高于http.
舉報