RPCを使用してREST Webサービスを実装するかどうかを決定しようとしています。 Googles eclipseプラグインは、RPCの主な魅力であるRPCサービスを非常に簡単に作成できます。 しかし、RESTサービスは、IMHOを変更するのが簡単であるように見えますが、将来のiOSクライアントがリワークをほとんどまたは全くしなくても接続できるようになります。 これはRPCの問題であるかもしれませんが、実際にはどのクライアントサーバーモデルでも既存のサービスを変更して新しいクライアントが新しい機能を使用できるようにしながら古いクライアントを動作させることができます。 私は、既存のクライアントを壊さないように、またはアップグレードを強制するようにWebサービスを変更するときに注意すべき点を教えてください。これをカバーするリンクがあればご了承くださいAndroidクライアントとRPCを使用したREST Webサービス
ここにはいくつかの考えがあります。まず、同様の質問で指摘したように、RESTとRPCを比較するのは実際には意味がありません。 RESTは、特定の目標を達成するためにインターフェイスに課すことができる一連の制約であり、RPCインターフェイスは実際にはRESTfulにすることができます。詳細については、thisブログ記事をご覧ください。
質問の2番目の部分に応じて、カスタムRPCインターフェイスでは、クライアントが呼び出すメソッドについて知る必要があります。つまり、公開されているプロシージャのAPIが変更され、新しい（RESTfulインターフェイスでは、法的措置は通常、すべてサーバーによって制御されます）。私がリンクしたブログ記事ではこれについていくつか詳しく述べています。
複数のバージョンのサービスを並べて展開する1つのアプローチは、プロダクション・マルチテナントでサービス・バージョンをロールし、任意のクライアント・メタデータに基づいて正しいサービス・バージョンに要求をディスパッチすることです。たとえば、あなたのサービスは、サーブレットを経由してRPCのWeb APIを公開する場合は、次のことができます。Class Loader分離とTomcatの中に並んでRPCサービス側の複数のバージョンのブートストラップ
最善の解決策は、旧バージョンの間にサーバー上で並行して複数のバージョンを実行することです法的措置を制御するサーバーのないように、クライアントの複数のバージョンは、野生でいつでも存在しますクライアントは推奨されなくなりました。