2

我已经使用 RPC 多年，但现在我们必须使用 REST。我试图了解两者之间的差异以及其中一个如何优于另一个。因此，我阅读了很多文章，试图完全理解其中的微妙之处。到目前为止，它看起来不错，但有一些小问题。

我理解（至少我认为我理解），将事物共享为通过使用动词 GET、PUT 等获取的资源的一般概念。这很好地映射到大多数服务器访问概念，但还有其他想法可以不那么容易映射。例如，我需要通知服务器下载一个 gravatar 图像并存储它。我不确定这如何适合 RESTful 端点。

请注意，我知道如何将 RPC 伪装成 REST，但我对此不感兴趣。我想以“REST方式”来做这件事，如果没有其他原因，只是为了了解这种方式实际上是什么。

4

1 回答 1

3

是的，在大多数情况下，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

但在我看来，你已经知道了。那么复杂的场景呢。他们有很多。作为问题的例子：

例如，我需要通知服务器下载一个 gravatar 图像并存储它。我不确定这如何适合 RESTful 端点。

我不认为它很难映射到 REST。一切都取决于细微差别。例如，当用户选择“gravatar”选项时，为什么在注册用户时不这样做。或者为什么不拥有 GET http://bookslirarysample.com/users/15/gravatar。REST 没有问题。

但也许您不仅假设 REST 端点或如何说服务器。当然，在 gravatar 下的功能不仅仅是 REST 调用。服务器上可能是消息总线，您的 REST 服务器通过它发送消息。特殊的“下载器”服务将收到此消息，下载图像，将其存储并保存到具有某些 id 的用户 oject。REST 并没有减少它背后的巨大服务器基础设施。REST 外观背后可能是复杂的企业级事件驱动架构。这对 REST 来说不是问题。

无论如何，还有更高级的场景。像通知聚合、事务、安全等。其中许多在 Jim Webber 的书中都有很好的描述：

REST 实践：超媒体和系统架构

于 2012-06-15T09:07:02.313 回答