到這里為止我們看到針對RPC 的討論基本都是在討論設計、實現、面向對象、性能、分布式問題如何解決。有一點好像被忽略了，那就是易用性。為什么呢？是因為當時的程序員喜歡復雜的技術么？
而到了90年代后期，互聯網已經開始普及，隨著web 開發的興起，開發者也以指數的速度增長，這時開發框架就不僅僅要考慮小部分人的使用體驗而是要照顧大多數人的使用體驗了。
1996 年，HTTP/1.0 版本發布，大大豐富了 HTTP 的傳輸內容，除了文字，還可以發送圖片、視頻等，這為互聯網的發展奠定了基礎。
相比 HTTP/0.9，HTTP/1.0 主要有如下特性：
在 HTTP/1.0 發布幾個月后，HTTP/1.1 就發布了。HTTP/1.1 更多的是作為對 HTTP/1.0 的完善
1994年12月，CORBA 2.0 就已經發布規范，該規范希望能夠解決不同廠商根據COBRA規范所開發的產品“互聯互不通”的嚴重問題，但直到1997年，Corba2.0 才正式發布，但是最后還是失敗了。至于COBRA失敗的原因，COBRA陣營的技術大牛、COBRA技術的推動者，即后來加入反COBRA陣營的Michi Henning，在他的《The rise and fall of CORBA》書里做了如下深刻的總結。
最初參與CORBA 的一批技術專家不滿CORBA 的設計，另起爐灶打造了新的RPC—即 ZeroC Ice，ICE 最初的廣告語為“反叛之冰”。它也一直延續至今，發展成了一個強大的微服務架構平臺。
1998 年 XML 1.0 發布，被 W3C (World Wide Web Consortium) 推薦為標準的描述語言。同年，微軟和DevelopMentor發布SOAP（Simple Object Access Protocol），隨后提交給W3C作為標準。SOAP是一個嚴格定義的信息交換協議，使用XML作為RPC新的對象序列化機制，用于在Web Service中把遠程調用和返回封裝成機器可讀的格式化數據。由此誕生了SOAP API，被廣泛用于企業內部及上下游企業直接的應用集成。
SOAP 的協議約定用的是 WSDL (Web Service Description Language) ，這是一種 Web 服務描述語言，在服務的客戶端和服務端開發者不用面對面交流，只要用的是 WSDL 定義的格式，客戶端知道了 WSDL 文件，就知道怎么去封裝請求，調用服務。
SOAP 是用 HTTP 進行傳輸的，信息有 Header 和 Body，SOAP 的請求和回復都放在消息中，進行傳遞。
SOAP 的服務發現用的是 UDDI（Universal Description, Discovery, Integration) 統一描述發現集成，相當于一個注冊中心，服務提供方將 WSDL 文件發布到注冊中心，使用方可以到這個注冊中心查找。
SOAP嚴格意義上是屬于XML-RPC（XML Remote Procedure Call）技術的一個變種，一個XML-RPC請求消息就是一個HTTP-POST請求消息，其請求消息主體基于XML格式。客戶端發送XML-RPC請求消息到服務端，調用服務端的遠程方法并在服務端上運行遠程方法。遠程方法執行完畢后返回響應消息給客戶端，其響應消息主體同樣基于XML格式。遠程方法的參數支持數字、字符串、日期等，也支持列表數組和其他復雜結構類型，SOAP是第一次真正成功地解決了多語言多平臺支持的開放性RPC標準。
不過SOAP也有很多不足：
這又和 Waldo 的經典結論保持了一致：
嘗試讓遠程調用的行為像本地調用的代價是不可忽略的。
之后，大家開始慢慢拋棄SOAP標準中過程化、分層的概念，開始轉向更簡單的Rest傳輸方式。
2000年，Roy Thomas Fielding 博士在他的博士論文 《Architectural Styles and the Design of Network-based Software Architectures》首次提出了 REST 這個詞。由此誕生了RESTful API，被廣泛用于企業對外的開放API戰略中，真正意義上奠定了API經濟的基石，至今已經發成為萬億美元以上的一個市場。
REST提供了一系列架構約束，當作為整體使用時，它強調組件交互的可擴展性、接口的通用性、組件的獨立部署，以及那些能減少交互延遲的中間件，它強化了安全性，也能封裝遺留系統。
—- Roy Fielding
REST 不是協議而是一種使用HTTP 協議的進程間通信機制。REST非常簡單，無需客戶端stub 代碼 和服務端 stub代碼，且所有語言都可以集成實現。HTTP REST慢慢侵占了RPC大部分應用領地的“異類”，并且導致了一度盛行的XML-RPC的滅絕，但同時促進了正統RPC技術走向一個新的發展階段，追求更高的性能及增加對多語言多平臺的支持，成為越來越多的開源RPC框架的目標，典型的代表為Thrift、Apache Avro等新生的開源框架，這些框架在大數據系統、大型分布式系統及移動互聯網應用方面被越來越多的公司使用。
Protocol Buffers 是一種輕便高效的結構化數據存儲格式，可以用于結構化數據序列化，很適合做數據存儲或 RPC 數據交換格式。它可用于通訊協議、數據存儲等領域的語言無關、平臺無關、可擴展的序列化結構數據格式。
Thrift 是一個跨語言的服務部署框架，最初由Facebook于2007年開發，2008年進入Apache開源項目。Thrift通過一個中間語言(IDL, 接口定義語言)來定義RPC的接口和數據類型，然后通過一個編譯器生成不同語言的代碼（目前支持C++,Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk和OCaml）,并由生成的代碼負責RPC協議層和傳輸層的實現。
Thrift 和 Protocol Buffer 不同，它不僅僅是一個數據序列化工具，而是一個完整的RPC 框架。另一個不同點在于，Protobuf 標準化了單一的二進制編碼方式，但Thrift 則包含了多種不同的序列化方式（Thirft 稱之為協議）。
Apache Avro 是一個基于二進制數據傳輸高性能的中間件，在2009年成為 Hadoop 中的一個子項目，并與2015年脫離Hadoop，加入Apache成為一個獨立的項目。
Avro 同樣支持跨編程語言實現（C, C++, C#，Java, Python, Ruby, PHP），Avro 提供著與諸如 Thrift 和 Protocol Buffers 等系統相似的功能，但是在一些基礎方面還是有區別的，主要是：
Avro 和動態語言結合后，讀/寫數據文件和使用 RPC 協議都不需要生成代碼，而代碼生成作為一種可選的優化只需要在靜態類型語言中實現。
當在 RPC 中使用 Avro 時，服務器和客戶端可以在握手連接時交換模式。服務器和客戶端有著彼此全部的模式，因此相同命名字段、缺失字段和多余字段等信息之間通信中需要解決的一致性問題就可以容易解決。
還有，Avro 模式是用 JSON（一種輕量級的數據交換模式）定義的，這樣對于已經擁有 JSON 庫的語言可以容易實現。
可以看到的是，avro 相對pb 和 thrift 來說更簡單一點。
WebSocket是一種計算機通信協議，通過單個傳輸控制協議(TCP) 連接提供同步雙向通信通道。WebSocket 協議于 2011 年由IETF標準化為 RFC 6455。當前允許 Web 應用程序使用此協議的規范稱為WebSockets。它是WHATWG維護的現行標準，是W3C的WebSocket API的后繼者。
WebSocket 協議支持Web 瀏覽器（或其他客戶端應用程序）與Web 服務器之間的全雙工交互，其開銷比半雙工替代方案（如 HTTP輪詢）更低，從而有助于實現與服務器之間的實時數據傳輸。這是通過為服務器提供一種標準化的方式來實現的，即服務器無需先由客戶端請求即可將內容發送到客戶端，并允許在保持連接打開的同時來回傳遞消息。這樣，客戶端和服務器之間就可以進行雙向的持續對話。通信通常通過 TCP端口號 443（或在非安全連接的情況下為 80）進行，這對于使用防火墻阻止非 Web 互聯網連接的環境非常有用。此外，WebSocket 在 TCP 之上支持消息流。TCP 本身處理字節流，沒有消息的固有概念。類似的雙向瀏覽器-服務器通信已經通過非標準化方式使用權宜之計技術（如Comet或Adob??e Flash Player）實現。
雖然 HTTP/1.1 已經優化了很多點，作為一個目前使用最廣泛的協議版本，已經能夠滿足很多網絡需求，但是隨著網頁變得越來越復雜，甚至演變成為獨立的應用，HTTP/1.1 逐漸暴露出了一些問題：
2015 年，Google 將gRPC框架開源，gRPC 使用 PB 作為序列化的解決方案，而在傳輸的介質上使用了 HTTP/2而不是常見的TCP。gRPC 是一個多路復用、雙向流式 RPC 協議。在一般的 RPC 機制中，客戶端發起到服務器的連接，只有客戶端可以請求，而服務器只能響應傳入的請求。然而，在雙向 gRPC 流中，雖然初始連接是由客戶端發起的(稱為端點1) ，但是一旦建立連接，服務器(稱為端點2)和端點1都可以發送請求和接收響應。這極大地簡化了兩個端點相互通信的開發(如網格計算)。由于兩個數據流都是獨立的，這也省去了在端點之間創建兩個獨立連接的麻煩(一個從端點1到端點2，另一個從端點2到端點1)。