GWT-RPC vs HTTP Call - 哪個更好？

我在評估使用GWT-RPC和HTTP Call進行的調用之間是否存在性能差異。GWT-RPC vs HTTP Call - 哪個更好？

我的appln服務是作爲Java servlet託管的，我目前使用HTTPProxy連接從它們獲取數據。我期待將它們轉換爲GWT-RPC調用，如果這會帶來性能改進。

我想了解每個優點/缺點...

而且對工具有什麼建議來衡量的異步調用的性能...

[可與GWT使用A good article on various Server communication strategies]

2010-06-02 Nirmal Patel

僅供參考，您的HTTP調用鏈接轉到GWT 1.5文檔 - 可能會有2.0（或2.1）版本的新鮮文檔。 – 2010-06-02 05:36:24

對於交叉引用，OP還在GWT郵件列表上提出了這個問題 - http://groups.google.com/group/google-web-toolkit/browse_thread/thread/1bea9f0de836885c – 2010-06-02 06:44:07

我寫了文章中提到的文章（感謝您的鏈接！）。

一如既往，答案是'它取決於'。我使用了GWT-RPC和JSON。

如上所述，GWT-RPC允許通過網絡傳送java對象（帶有一些限制）的一些嚴重生產力。一些邏輯可以共享，GWT負責編組/解組對象。

JSON允許其他非GWT客戶端跨域訪問和使用。你可以通過覆蓋類型獲得，但不能共享行爲（如驗證）。與GWT-RPC不同，JSON也可以很容易地進行壓縮和緩存（上次查看時）。

由於我們不知道有效載荷是什麼，性能建議很難給出。我建議（再次，像上面的人一樣）測試自己。

來源

2010-06-04 11:53:05 mooreds

當後端也使用Java編寫時，通常首選GWT-RPC，因爲它意味着不必在每一端對對象進行編碼和解碼 - 您只需將常規Java對象傳輸到客戶端，然後在其中使用它。

JSON（使用RequestBuilder）通常用於以其他語言編寫後端，並要求服務器將響應對象和客戶端JSON編碼爲JSON時將其解碼爲用於GWT代碼的JavaScriptObject 。

如果我不得不猜測，我會說GWT-RPC也會導致較小的傳輸對象，因爲GWT團隊針對這種情況進行了優化，但兩者都可以工作，JSON仍然很小。在大多數情況下，這只是爲了方便開發人員。對於測量請求時間的工具，您可以使用Chrome/Webkit的開發人員工具或Firefox的Firebug擴展，或者在您的應用程序中度量請求時間，然後將該度量數據發送回服務器，以延遲請求進行收集和分析。

來源

2010-06-02 05:31:46

同意。我還要補充一點：編碼GWT-RPC的速度非常快，所以你可能會在未來的增加中獲得生產力。 – Zwik 2010-06-02 12:16:11

總的來說，我同意Jason的觀點 - 如果你的服務器端使用Java，那就使用GWT-RPC。您將能夠重用POJO，驗證邏輯等.RPC還傾向於使用MVP和代碼分割「更好地發揮」。

但是，如果您的服務器端使用其他任何使用JSON - 但不要擔心，使用JSON JavaScript Overlay Types是一件輕而易舉的事情。（YMMV），您將無法重新使用服務器上客戶端的代碼。

從性能角度來看 - 我會說JSON在這裏有優勢。現代瀏覽器對於JSON的快速編碼/解碼有一些非常好的方法。我不確定什麼GWT-RPC是「幕後」的，但我懷疑它在速度方面可以擊敗JSON。至於有效負載 - 取決於開發人員（JSON中的對象的名稱等），但我會說，一般來說JSON也（可能）更小。在您的服務器上啓用壓縮（例如，mod_deflate on Apache HTTP）以擠壓這些位;）

來源

2010-06-02 17:57:30

除了其他答案之外，還有一點需要考慮哪些因素會影響您對JSON的決定，即使您正在使用Java在後端：

也許在將來某個時候，您希望允許非GWT客戶端與您的服務器進行通信。許多現代網站提供某種API訪問權限，如果您使用的是JSON，則基本上已經擁有相對開放的API。

來源

2010-06-02 22:02:03

GWT-RPC vs HTTP Call - 哪個更好？

回答

相關問題