RPC風のアプローチがRESTよりも適切なのはいつですか？

Steve VinoskiによるREST、Reuse、Serendipityに関するこの講演を見た後、（XML-）RPC-ishセットアップのグリーンフィールドプロジェクトにRESTがより良い方法で解決できなかったビジネスケースがあるのではないかと思います。

彼が言及したいくつかのRPC問題：

• 言語に焦点を当てる（分散システムをその言語に適合させ、その逆ではない）
• 「ローカルに見えるようにする」（およびルールではなく例外として障害と遅延に対処する）
• 言語に依存しないことを意図しているが、依然として主要な成分として言語間で「関数呼び出し」を持っている
• IDLボイラープレート
• 型の安全性の錯覚
• そして、さらにいくつか...

少しドラマ化するために、RPC vs RESTのGoogleインスタント結果をいくつか示します。

一般に、RPCはRESTよりもはるかに多くの言語統合を提供します。既に述べたように、特に単一の分散システムに複数の言語で記述されたコードを実行する複数のホストが含まれる場合、これにはスケール、エラー処理、型安全性などの点で多くの問題が伴います。ただし、RPC、REST、およびその両方を同時に使用するビジネスシステムを記述した後、特定の場合にRPCよりもRPCを選択する理由がいくつかあることがわかりました。

RPCの方が適していることがわかった場合を次に示します。

• 密結合。システムの（分散）コンポーネントは連携して動作するように設計されており、1つを変更すると他のすべてに影響を与える可能性があります。将来、他のシステムと通信するためにコンポーネントを適合させる必要はないでしょう。
• 信頼できるコミュニケーション。コンポーネントは、完全に同じホスト上で、または遅延問題、パケット損失などが発生する可能性が低いネットワーク上で相互に通信します（ただし、これらのケースを処理するようにシステムを設計する必要があります）。
• 統一言語。すべての（またはほとんどすべての）コンポーネントは単一の言語で記述されます。異なる言語で記述されたコンポーネントが将来追加されることはほとんどありません。

IDLについてのポイントに関して、RESTシステムでは、REST要求と応答のデータを、使用している内部データ表現に変換するコードを記述する必要もあります。IDLソース（適切なコメント付き）は、REST API用に個別に作成および保守する必要があるインターフェイスのドキュメントとしても機能します。

上記の3つの項目は、大規模なシステムの1つのコンポーネントを構築しようとしているときによく発生します。私の経験では、これらのコンポーネントは多くの場合、サブシステムが独立して故障する必要があるものであり、他のサブシステムまたはコンポーネント全体の全体的な故障を引き起こさないものです。多くのシステムは、これらの目標を達成するためにErlangで作成されており、場合によっては、これらの利点を得るためだけにRPCを使用して別の言語でシステムを作成するよりもErlangの方が適している場合があります。

ほとんどのエンジニアリングの問題と同様に、プロセス間通信の問題に対する単一の解決策はありません。設計しているシステムを見て、ユースケースに最適な選択をする必要があります。

データセンター全体で製品をスケールアップし、高可用性と負荷分散を行う場合、RESTにはいくつかの大きな利点があります。

ただし、小規模なプロジェクトについて考えてください。1時間に数百のリクエストがあるWebサービスが必要ですか？WCFは、すべてのトランスポートの問題を処理します。ネットワーク経由でオブジェクトを送信するための便利なインターフェイスがあり、application.configファイルのみを使用して、プログラミングなしでネットワーク接続を構成、暗号化、および認証できます。

実際には両方を持つことができます。Grails用のRestRPCのようなプラグインは、メソッドへの呼び出しをインターセプトし、必要な数（非常にRPCに似たもの）を保持しながらそれらを安全に処理するアノテーションを提供します。