我已经使用 RPC 多年，但现在我们必须使用 REST。我试图了解两者之间的差异以及其中一个如何优于另一个。因此，我读了很多文章，试图充分理解其中的微妙之处。到目前为止，看起来不错，但存在一些小问题。
我理解(至少我认为我理解)，将事物作为资源共享的一般思想是通过使用动词 GET、PUT 等获取的。这很好地映射到大多数服务器访问概念，但还有其他那些不那么容易映射的想法。例如，我需要通知服务器下载头像并存储。我不确定这如何适合 RESTful 端点。
请注意，我知道如何将 RPC 伪装成 REST，但我对此不感兴趣。我想以“REST 方式”执行此操作，如果没有其他原因，只是为了了解这种方式实际上是什么。
最佳答案
是的，在大多数情况下，RPC 风格的服务可以很好地映射到 REST。因此，CRUD 操作可以映射到任何合适的地方。无论如何，我们可以在第一阶段识别合约方法，将它们映射到 URI 和不同的 HTTP 动词。第二阶段是引入资源，可能它们以DTO对象的形式存在。
无论如何，从 RPC 到 REST(很可能是 2 级)的路线图在 Richardson 成熟度模型 (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
但在我看来你已经知道了。那么复杂的场景呢？他们有很多。以问题为例:
For example, I need to inform the server to download a gravatar image and store it. I'm not sure how that fits into a RESTful endpoint.
我认为它很难映射到 REST。一切都取决于细微差别。例如，当用户选择“gravatar”选项时，为什么不在注册用户时执行此操作。或者为什么不使用 GET http://bookslirarysample.com/users/15/gravatar 。对于 REST 来说这不是问题。
但也许您不仅假设 REST 端点或如何说服务器。当然，Gravatar 下的功能不仅仅是 REST 调用。服务器上可能是消息总线，您的 REST 服务器通过它发送消息。特殊的“下载器”服务将接收此消息，下载图像，存储它并使用某个 ID 保存到用户对象。 REST 并没有消除其背后巨大的服务器基础设施。 REST 外观背后可能是复杂的企业级事件驱动架构。对于 REST 来说这不是问题。
无论如何，还有更高级的场景。比如通知聚合、交易、安全等。其中许多在 Jim Webber 的书中都有很好的描述:
关于rest - 将 RPC 接口(interface)转换为 REST，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10969623/