劇多
首頁
資訊
體育
娛樂
汽車
投資
財經
軍事
科技
數碼
科學
遊戲
歷史
健康
政治
影視
旅遊
育兒
美食
時尚
房產
農業
社會
文化
教育
技術
美文
情感
故事
家居
職場
自然
闢謠
心理
攝影
漫畫
生活
其它
Club
Tips
熱門話題
搜尋
註冊
登入
首頁
>
Club
>
2021-02-02 10:44
怎麼呼叫webservice接口裡的方法?
14
回覆列表
1 # 使用者8326766278412
RPC(遠端過程呼叫)是什麼
簡單的說,RPC就是從一臺機器(客戶端)上透過引數傳遞的方式呼叫另一臺機器(伺服器)上的一個函式或方法(可以統稱為服務)並得到返回的結果。 RPC 會隱藏底層的通訊細節(不需要直接處理Socket通訊或Http通訊) RPC 是一個請求響應模型。客戶端發起請求,伺服器返回響應(類似於Http的工作方式) RPC 在使用形式上像呼叫本地函式(或方法)一樣去呼叫遠端的函式(或方法)。遠端過程呼叫發展歷程 ONC RPC (開放網路計算的遠端過程呼叫),OSF RPC(開放軟體基金會的遠端過程呼叫) CORBA(Common Object Request Broker Architecture公共物件請求代理體系結構) DCOM(分散式元件物件模型),COM+ Java RMI .NET Remoting XML-RPC,SOAP,Web Service PHPRPC,Hessian,JSON-RPC Microsoft WCF,WebAPI ZeroC Ice,Thrift,GRPC Hprose早期的 RPC第一代 RPC(ONC RPC,OSF RPC)不支援物件的傳遞。CORBA 太複雜,各種不同實現不相容,一般程式設計師也玩不轉。DCOM,COM+ 逃不出 Windows 的手掌心。RMI 只能在 Java 裡面玩。.NET Remoting 只能在 .NET 平臺上玩。XML-RPC,SOAP,WebService 冗餘資料太多,處理速度太慢。 RPC 風格的 Web Service 跨語言性不佳,而 Document 風格的 Web Service 又太過難用。 Web Service 沒有解決使用者的真正問題,只是把一個問題變成了另一個問題。 Web Service 的規範太過複雜,以至於在 .NET 和 Java 平臺以外沒有真正好用的實現,甚至沒有可用的實現。 跨語言跨平臺只是 Web Service 的一個口號,雖然很多人迷信這一點,但事實上它並沒有真正實現。PHPRPC基於 PHP 內建的序列化格式,在跨語言的型別對映上存在硬傷。通訊上依賴於 HTTP 協議,沒有其它底層通訊方式的選擇。內建的加密傳輸既是特點,也是缺點。雖然比基於 XML 的 RPC 速度快,但還不是足夠快。Hessian二進位制的資料格式完全不具有可讀性。官方只提供了兩個半語言的實現(Java,ActionScript 和不怎麼完美的 Python 實現),其它語言的第三方實現良莠不齊。支援的語言不夠多,對 Web 前端的 JavaScript 完全無視。雖然是動態 RPC,但動態性仍然欠佳。雖然比基於 XML 的 RPC 速度快,但還不是足夠快。JSON-RPCJSON 具有文字可讀性,且比 XML 更簡潔。JSON 受 JavaScript 語言子集的限制,可表示的資料型別不夠多。JSON 格式無法表示資料內的自引用,互引用和迴圈引用。某些語言具有多種版本的實現,但在型別影射上沒有統一標準,存在相容性問題。JSON-RPC 雖然有規範,但是卻沒有統一的實現。在不同語言中的各自實現存在相容性問題,無法真正互通。Microsoft WCF,WebAPI它們是微軟對已有技術的一個 .NET 平臺上的統一封裝,是對 .NET Remoting、WebService 和基於 JSON 、XML 等資料格式的 REST 風格的服務等技術的一個整合。雖然號稱可以在 .NET 平臺以外來呼叫它的這些服務,但實際上跟在 .NET 平臺內呼叫完全是兩碼事。它沒有提供任何在其他平臺的語言中可以使用的任何工具。ZeroC Ice,Thrift,GRPC初代 RPC 技術的跨語言面向物件的迴歸。仍然需要透過中間語言來編寫型別和介面定義。仍然需要用程式碼生成器來將中間語言編寫的型別和介面定義翻譯成你所使用的程式語言的客戶端和伺服器端的佔位程式(stub)。你必須要基於生成的伺服器程式碼來單獨編寫服務,而不能將已有程式碼直接作為服務釋出。你必須要用生成的客戶端程式碼來呼叫服務,而沒有其它更靈活的方式。如果你的中間程式碼做了修改,以上所有步驟你都要至少重複一遍。Hprose無侵入式設計,不需要單獨定義型別,不需要單獨編寫服務,已有程式碼可以直接釋出為服務。具有豐富的資料型別和完美的跨語言型別對映,支援自引用,互引用和迴圈引用資料。支援眾多傳輸方式,如 HTTP、TCP、Websocket 等。客戶端具有更靈活的呼叫方式,支援同步呼叫,非同步呼叫,動態引數,可變引數,引用引數傳遞,多結果返回(Golang)等語言特徵,Hprose 2.0 甚至支援推送。具有良好的可擴充套件性,可以透過過濾器和中介軟體實現加密、壓縮、快取、代理等各種功能性擴充套件。相容的無差別跨語言呼叫支援更多的常用語言和平臺支援瀏覽器端的跨域呼叫沒有中間語言,無需學習成本效能卓越,使用簡單
發表回復
∧
中秋節和大豐收的關聯?
∨
如何看待動漫《SSSS古利特》第五集中的泳衣福利?
熱門排行
一邊走路一邊直播用什麼設備?
毛衣生產基地哪裡最好?
寶媽半夜帶孩子崩潰文案?
給孩子們自制小籠包經典文案?
綠焰多肉可以曬太陽嗎?
tfboys為什麼有十週年?
準星跟隨怎麼設置?
怎麼給小芭比做衣服和裙子?
龍之業火怎麼洗詞條?
直飲機預留口怎麼遮擋?
RPC(遠端過程呼叫)是什麼
簡單的說,RPC就是從一臺機器(客戶端)上透過引數傳遞的方式呼叫另一臺機器(伺服器)上的一個函式或方法(可以統稱為服務)並得到返回的結果。 RPC 會隱藏底層的通訊細節(不需要直接處理Socket通訊或Http通訊) RPC 是一個請求響應模型。客戶端發起請求,伺服器返回響應(類似於Http的工作方式) RPC 在使用形式上像呼叫本地函式(或方法)一樣去呼叫遠端的函式(或方法)。遠端過程呼叫發展歷程 ONC RPC (開放網路計算的遠端過程呼叫),OSF RPC(開放軟體基金會的遠端過程呼叫) CORBA(Common Object Request Broker Architecture公共物件請求代理體系結構) DCOM(分散式元件物件模型),COM+ Java RMI .NET Remoting XML-RPC,SOAP,Web Service PHPRPC,Hessian,JSON-RPC Microsoft WCF,WebAPI ZeroC Ice,Thrift,GRPC Hprose早期的 RPC第一代 RPC(ONC RPC,OSF RPC)不支援物件的傳遞。CORBA 太複雜,各種不同實現不相容,一般程式設計師也玩不轉。DCOM,COM+ 逃不出 Windows 的手掌心。RMI 只能在 Java 裡面玩。.NET Remoting 只能在 .NET 平臺上玩。XML-RPC,SOAP,WebService 冗餘資料太多,處理速度太慢。 RPC 風格的 Web Service 跨語言性不佳,而 Document 風格的 Web Service 又太過難用。 Web Service 沒有解決使用者的真正問題,只是把一個問題變成了另一個問題。 Web Service 的規範太過複雜,以至於在 .NET 和 Java 平臺以外沒有真正好用的實現,甚至沒有可用的實現。 跨語言跨平臺只是 Web Service 的一個口號,雖然很多人迷信這一點,但事實上它並沒有真正實現。PHPRPC基於 PHP 內建的序列化格式,在跨語言的型別對映上存在硬傷。通訊上依賴於 HTTP 協議,沒有其它底層通訊方式的選擇。內建的加密傳輸既是特點,也是缺點。雖然比基於 XML 的 RPC 速度快,但還不是足夠快。Hessian二進位制的資料格式完全不具有可讀性。官方只提供了兩個半語言的實現(Java,ActionScript 和不怎麼完美的 Python 實現),其它語言的第三方實現良莠不齊。支援的語言不夠多,對 Web 前端的 JavaScript 完全無視。雖然是動態 RPC,但動態性仍然欠佳。雖然比基於 XML 的 RPC 速度快,但還不是足夠快。JSON-RPCJSON 具有文字可讀性,且比 XML 更簡潔。JSON 受 JavaScript 語言子集的限制,可表示的資料型別不夠多。JSON 格式無法表示資料內的自引用,互引用和迴圈引用。某些語言具有多種版本的實現,但在型別影射上沒有統一標準,存在相容性問題。JSON-RPC 雖然有規範,但是卻沒有統一的實現。在不同語言中的各自實現存在相容性問題,無法真正互通。Microsoft WCF,WebAPI它們是微軟對已有技術的一個 .NET 平臺上的統一封裝,是對 .NET Remoting、WebService 和基於 JSON 、XML 等資料格式的 REST 風格的服務等技術的一個整合。雖然號稱可以在 .NET 平臺以外來呼叫它的這些服務,但實際上跟在 .NET 平臺內呼叫完全是兩碼事。它沒有提供任何在其他平臺的語言中可以使用的任何工具。ZeroC Ice,Thrift,GRPC初代 RPC 技術的跨語言面向物件的迴歸。仍然需要透過中間語言來編寫型別和介面定義。仍然需要用程式碼生成器來將中間語言編寫的型別和介面定義翻譯成你所使用的程式語言的客戶端和伺服器端的佔位程式(stub)。你必須要基於生成的伺服器程式碼來單獨編寫服務,而不能將已有程式碼直接作為服務釋出。你必須要用生成的客戶端程式碼來呼叫服務,而沒有其它更靈活的方式。如果你的中間程式碼做了修改,以上所有步驟你都要至少重複一遍。Hprose無侵入式設計,不需要單獨定義型別,不需要單獨編寫服務,已有程式碼可以直接釋出為服務。具有豐富的資料型別和完美的跨語言型別對映,支援自引用,互引用和迴圈引用資料。支援眾多傳輸方式,如 HTTP、TCP、Websocket 等。客戶端具有更靈活的呼叫方式,支援同步呼叫,非同步呼叫,動態引數,可變引數,引用引數傳遞,多結果返回(Golang)等語言特徵,Hprose 2.0 甚至支援推送。具有良好的可擴充套件性,可以透過過濾器和中介軟體實現加密、壓縮、快取、代理等各種功能性擴充套件。相容的無差別跨語言呼叫支援更多的常用語言和平臺支援瀏覽器端的跨域呼叫沒有中間語言,無需學習成本效能卓越,使用簡單