GWT-RPC とHTTP Callを使用して行われた呼び出しの間にパフォーマンスのばらつきがあるかどうかを評価しています。
私の appln サービスは Java サーブレットとしてホストされており、現在 HTTPProxy 接続を使用してそれらからデータを取得しています。パフォーマンスが向上する場合は、それらを GWT-RPC 呼び出しに変換することを検討しています。
それぞれのメリット・デメリットを知りたい...
また、非同期呼び出しのパフォーマンスを測定するツールに関する提案...
[ GWT で使用できるさまざまなサーバー通信戦略に関する優れた記事]
GWT-RPC は一般に、バックエンドも Java で記述されている場合に好まれます。これは、両端でオブジェクトをエンコードおよびデコードする必要がないことを意味するためです。通常の Java オブジェクトをクライアントに送信し、そこで使用するだけです。
JSON ( を使用RequestBuilder) は通常、バックエンドが他の言語で記述されている場合に使用され、サーバーが応答オブジェクトを JSON エンコードし、クライアントがJavaScriptObjectGWT コードで使用するためにそれを JSON デコードする必要があります。
GWT チームがこのケースに合わせて最適化しているため、GWT-RPC もトランスポート オブジェクトが小さくなると推測する必要がありますが、どちらでも機能し、JSON は依然としてかなり小さい可能性があります。ほとんどの場合、開発者の利便性の問題になります。
リクエスト時間を測定するツールについては、Chrome/Webkit の開発者ツールまたは Firefox の Firebug 拡張機能を使用するか、アプリでリクエスト時間を測定し、収集と分析のために遅延リクエストでそのメトリクス データをサーバーに送り返すことができます。
私は質問で言及されたその記事を書きました（リンクに感謝します！）。
いつものように、答えは「状況によって異なります」です。私はGWT-RPCとJSONの両方を使用しました。
上で概説したように、GWT-RPCは、Javaオブジェクト（いくつかの制限付き）をネットワーク経由で出荷する際に、かなりの生産性を可能にします。一部のロジックは共有でき、GWTがオブジェクトのマーシャリング/アンマーシャリングを処理します。
JSONは、他の非GWTクライアントによるクロスドメインアクセスと消費を可能にします。オーバーレイタイプでうまくいくことはできますが、動作（検証など）を共有することはできません。JSONは、GWT-RPC（前回調べたとき）とは異なり、簡単に圧縮してキャッシュすることもできます。
ペイロードが何であるかわからないため、パフォーマンスの推奨事項を提示するのは困難です。（もう一度、誰かが上で行ったように）自分でテストすることをお勧めします。
他の回答に加えて、バックエンドで Java を使用している場合でも、JSON に対する決定に影響を与える可能性のある考慮すべき点が 1 つあります。
将来的には、GWT 以外のクライアントがサーバーと通信できるようにする必要があるかもしれません。最新のサイトの多くは何らかの API アクセスを提供しており、JSON を使用している場合は、基本的に既に比較的オープンな API を使用しています。
一般的に、Jason に同意します。サーバー側で Java を使用している場合は、GWT-RPC を使用してください。POJO、検証ロジックなどを再利用できるようになります。RPC は、MVP とコード分割でより適切に "再生" する傾向もあります。
ただし、サーバー側で他のものを使用する場合は、JSON を使用しますが、JSON を使用するJavaScript オーバーレイ タイプを使用すると簡単です。ただし、サーバー上のクライアント側からコードを再利用することはできません (YMMV)。
パフォーマンスの観点からは、ここでは JSON が有利であると言えます。最新のブラウザーには、JSON の高速なエンコード/デコードのための非常に優れた方法がいくつかあります。GWT-RPC が「舞台裏」にあるのかどうかはわかりませんが、速度に関しては JSON に勝てるとは思えません。ペイロードについては、開発者 (JSON 内のオブジェクトの名前など) によって異なりますが、一般的には JSON も (わずかに) 小さいと言えます。サーバーで圧縮を有効にして ( Apache HTTP の mod_deflateなど)、ビットをさらに圧縮します ;)