私は何年もRPCを使用してきましたが、現在はRESTを使用しなければならない状況にあります。私は、この2つの違いと、一方が他方よりも優れている可能性があることを理解しようとしています。そのため、私は微妙な点を完全に理解しようとして多くの記事を読みました。これまでのところ、それは良いように見えますが、いくつかのわずかな問題があります。
動詞GET、PUTなどを使用して取得されるリソースとして物事を共有するという一般的な考え方を理解しています（少なくとも私はそう思います）。これはほとんどのサーバーアクセスの概念によく対応していますが、他にもそれほど簡単にマッピングすることはできません。たとえば、Gravatarイメージをダウンロードして保存するようにサーバーに通知する必要があります。それがRESTfulエンドポイントにどのように適合するかはわかりません。
私はRESTを装ったRPCを実行する方法を知っていますが、それには興味がないことに注意してください。その方法が実際に何であるかを理解する以外の理由がなければ、私はこれを「REST方法」にしたいです。
はい、ほとんどの場合、RPCスタイルのサービスはRESTへの適切なマッピングです。したがって、CRUD操作は適切な場所にマッピングされます。とにかく、最初の段階でコントラクトメソッドを識別して、それらをURIとさまざまなHTTP動詞にマップできます。第2段階は、リソースを導入することです。リソースがDTOオブジェクトの形式で存在する場合もあります。
とにかく、RPCからREST（おそらくレベル2）へのロードマップは、Richardson Maturity Model（RMM）で適切に説明されています。
レベル0： SOAP、XML RPC、POX、単一URI
レベル1： URIトンネリング、多数のURI、単一の動詞
レベル2：多くのURI、多くの動詞、CRUDサービス（Amazon S3など）
レベル3：レベル2+ハイパーメディアRESTfulサービス
RMMの詳細はこちら：
http://code.google.com/p/implementing-rest/wiki/RMM http://martinfowler.com/articles/richardsonMaturityModel.html
しかし、あなたはすでにそれを知っているように私には思えます。では、複雑なシナリオについてはどうでしょうか。それらはたくさんあります。質問からの例として：
たとえば、Gravatarイメージをダウンロードして保存するようにサーバーに通知する必要があります。それがRESTfulエンドポイントにどのように適合するかはわかりません。
それがRESTにほとんどマッピングされていないと思います。そして、すべてはニュアンスに依存します。例として、ユーザーが「gravatar」オプションを選択したときにユーザーを登録しているときにそれを行わないのはなぜですか。または、 GEThttp://bookslirarysample.com/users/15/gravatarを使用しないのはなぜですか。RESTでは問題ありません。
しかし、RESTエンドポイントやサーバーの言い方だけではないと想定しているかもしれません。もちろん、Gravatar機能の下にはREST呼び出しだけではありません。サーバー上でメッセージバスである可能性があり、RESTサーバーはそれを介してメッセージを送信します。特別な「ダウンローダー」サービスがこのメッセージを受信し、画像をダウンロードして保存し、IDを付けてユーザーオブジェクトに保存します。RESTは、その背後にある巨大なサーバーの混乱を否定していません。RESTファサードの背後には、複雑なエンタープライズレベルのイベント駆動型アーキテクチャが存在する可能性があります。そしてそれはRESTにとって問題ではありません。
とにかく、より高度なシナリオがあります。通知の集約、トランザクション、セキュリティなどのように。多くは、JimWebberの本でよく説明されています。