RESTというアプローチは、単にアプリケーションAがHTTPプロトコルを使用してアプリケーションB（および場合によっては逆の）の要求を行うことを意味します。 JSONは今日のデフォルトです（そして、XMLは昨日のデフォルトでした...そしてSOAP - gaq！）。しかし、データの送信は好きなフォーマットにすることができます。
最近では、Amazon、Googleマップ、Yelpなどなど、大部分の外部APIがこのように実装されています。なぜですか？ HTTP（またはHTTPS）プロトコルはよく理解され、広く展開されているためです。特殊な設定は必要ありません。また、Webブラウザーの通常の人にアプリケーションを提供するのと同じプロトコルが、他のアプリケーションでも機能します。 Railsはこれを素晴らしく簡単にします（もしあなたがフローに合っていれば）。
JavaのRMIは特定のプロトコルです（HTTPと同様）。利点は、Aで定義されたオブジェクトがBのインスタンスとして利用可能であることです（両方で大量の作業が行われた後）。これは、アプリケーションのセットがすべて一緒に作業するように設計されていて、主要な要件が場所、サーバーなどに分散されている場合には、実際には意味があります。アプリケーション間に緊密なバインディングが作成されます。もう片方に。いくつかの種類のアプリケーションにとって適切です。
しかし、お互いに話し合っているが、「ヒップで縛られたくない」という2つの部門がある場合、RESTインターフェイスは大きな柔軟性を提供します。
あなたの2番目の質問（「どのくらい重い」）は答えるのが非常に難しいです。私が2001年に働いていた会社には、何百ものサーバーがすべて「ワーカー」プロセスのインスタンスを実行していました。それらはすべて結果を「コントローラ」プロセスにキューイングして出力を処理し、データの処理と管理を行います。 2001年には、サーバーがいっぱいの部屋で実行されるイントラネットの単一サブネット上での持続的なソケット接続が完全に連携して設計されていたため、これは適切なアーキテクチャでした。今や2012年には、サーバーがいっぱいになっているこの部屋は、64ビットOSを搭載した大量の高性能プロセッサーに置き換えられ、膨大な量のメモリーに対応しています。全く新しい世界です。 2001年の業績が2倍になると、ハードウェア、運用サポート、スペースなどが何百万ドルも節約される可能性があります。 2012年に、最も高価なものは良い開発者です！だから、「重い」は、最近の計算集約型の操作を除いて、無関係なものです。 HTTPリクエストは軽くシンプルです。
最終的な質問：ネイティブに理解されたバイナリ形式。もちろん、必要ならば。最後に、2つのサーバー間でワイヤを介して送信されるバイナリ形式は、シリアル化され、ストリームとしてデシリアライズされる必要があります。これは、プログラマ用とマシン用の両方で動作します。 JSONはテキスト形式ですが、JavaScript（JavaScript Object Notation）によってネイティブに理解され、人間が読めるという明確な利点があります。ほとんどのサーバーは、テキストやバイナリが何か関連性が低くなるかどうかを問わず、自動的に出力を圧縮するように設定されているため、少なくともI/Oとペイロードが行く限りです。もちろんはとなります。これは相互に理解できる形式を思い出してHTTPで送信しますが、これも10年前のことですが、今日は通常考慮する価値の問題ではありません。プロセッサはますます高速化されており、メモリーも安く（そしてより大きい） - 現代のアプリケーションではI/O（ネットワークまたはディスクのいずれか）が典型的なボトルネックになっています。
何百もの（今日の）サーバーが相互運用するように設計された（多くの）ピアサーバと通信する必要があった2001年のアプリケーションを再設計する場合は、シリアライズ/デシリアライズプロセスはできるだけ軽量でした（ただし、の場合はがボトルネックになっていました）。私にとって、特定のプラットフォームや言語に縛られることは、初心者ではありません。コンピューティングの世界は急速に進んでいます。
今日のほとんどすべての現実的なビジネスアプリケーションでは、単純で標準的で簡単なものを維持することは、過去のことを強く心配する必要性を現在と将来の利益の両方にもたらします。
希望:-)
鮮明な書き込み。ありがとう。あなたがここで言及した理由のいくつかを聞いたことがあります。 – sandeepkunkunuru