我已经使用RPC多年了，但现在我们必须使用REST。我试图理解两者之间的差异以及一个人如何优于另一个人。因此，我已经阅读了很多文章，试图完全理解这些细微之处。到目前为止，它似乎很好，但有一些小问题。
我理解（至少我认为我这样做），将事物分享为通过使用动词GET，PUT等获得的资源的一般想法。这很好地映射到大多数服务器访问概念，但还有其他不容易映射的想法。例如，我需要通知服务器下载一个gravatar图像并存储它。我不确定它是如何适应RESTful端点的。
请注意我知道如何将RPC伪装成REST，但我对此并不感兴趣。我想做这个“REST方式”，如果没有其他原因，除了理解实际上是什么方式。
答案 0 :(得分：2)
是的，在大多数情况下，RPC样式服务很好地映射到REST。因此，CRUD操作映射到任何好的地方。无论如何，我们可以在第一阶段识别合同方法，将它们映射到URI和不同的HTTP动词。第二阶段是引入资源，可能是它们以DTO对象的形式存在。
无论如何，在理查森成熟度模型（RMM）中描述了从RPC到REST（最有可能是第2级）的路线图：
0级： SOAP，XML RPC，POX，单个URI
第1级： URI隧道，多个URI，单个动词
第2级：许多URI，许多动词，CRUD服务（例如Amazon S3）
第3级：第2级+超媒体REST服务
有关RMM的更多信息：
http://code.google.com/p/implementing-rest/wiki/RMM http://martinfowler.com/articles/richardsonMaturityModel.html
但在我看来你已经知道了。那么复杂的场景呢？有很多。例如问题：
例如，我需要通知服务器下载一个gravatar图像 并存储它。我不确定它是如何适应RESTful端点的。
我不认为它很难映射到REST。一切都取决于细微差别。例如，当用户选择“gravatar”选项时，为什么不在注册用户时这样做。或者为什么不获得GET http://bookslirarysample.com/users/15/gravatar。这不是REST的问题。
但也许您不仅假设REST端点或如何说服务器。当然，在gravatar功能下不仅是REST调用。在服务器上可以是消息总线，您的REST服务器通过它发送消息。特殊的“下载程序”服务将收到此消息，下载图像，存储它并保存到具有一些ID的用户对象。 REST并没有决定它背后的巨大服务器infrusturuture。 REST外观背后可能是复杂的企业级事件驱动架构。这对REST来说不是问题。
无论如何还有更高级的场景。就像通知聚合，交易，安全等一样。许多人在Jim Webber的书中都有很好的描述：