RPC 伪装成 REST 是个坏主意吗？答案

【问题标题】：Is RPC disguised as REST a bad idea?RPC 伪装成 REST 是个坏主意吗？
【发布时间】：2010-09-28 00:04:59
【问题描述】：

我们的整个系统是围绕 REST 进行设计的，现在正在考虑如何在不使用 URL 中的动词的情况下将意图非常明确的 RPC 进程映射到 RESTful 资源。当内容列表在其他地方被修改时，我们的远程过程调用用于重建我们的搜索索引。

我们正在考虑这样做：

POST /index_updates

<indexUpdate><contentId>123</contentId></indexUpdate>

这本身没有问题，但气味是这个已创建的资源不返回新创建资源的 URL，例如/index_updates/1234 然后我们可以使用 GET 访问它。

我们使用的索引引擎确实有一个日志机制，所以理论上我们可以返回一个指向 index_update 资源的 URL，以便允许 GET 检索资源，但老实说，我们对资源不感兴趣因为这只不过是一个伪装的 RPC。

所以我的问题是 RESTfulness 是用结构还是意图来表达的。我觉得我所概述的结构是宁静的，但意图却不是。

有人有cmets或建议吗？

谢谢，

克里斯

【问题讨论】：

标签： web-services rest rpc

【解决方案1】：

为工作使用正确的工具。在这种情况下，似乎正确的工具是纯远程过程调用，没有理由假装它是 REST。

【讨论】：

同意，但是 REST 对我们的办公室来说是新事物，而且从行动到资源的思维转变被证明是困难的。目前我想避免让 RPC over HTTP 混入其中，因为这可能会为开发人员打开大门，让他们回归 RPC，这对他们来说更容易。
在我看来，解决方案是利用这个机会，而不是“滑坡”。解释为什么这是 RPC 的合适情况，以及为什么您的一般架构使用 REST。没有冲突。
是的，这也是我现在的想法，我认为我们不需要soap的复杂性，只需要通过HTTP进行简单的RPC调用，并清楚地向大家解释为什么使用RPC这种情况下，而不是逃避或试图隐瞒事实。好电话。

【解决方案2】：

您可能从 POST /index_updates 调用返回新资源标识符的一个原因是监控操作的状态。

POST /index_updates
123

201 Created
Location: /index_updates/a9283b734e

GET /index_jobs/a9283b734e

 <index_update><percent_complete>89</percent_complete></index_update>

【讨论】：

好主意，这是一个长度操作，所以有状态详细信息会很有用。
+1 如果您不希望在新资源上公开任何动词，则 IMO POST 不必返回新位置。并且|或者甚至在 /index_updates/123 上为所有动词返回 405 可能是一个解决方案？？

【解决方案3】：

这显然是一个主观领域，但 GET PUT POST DELETE 是一个足够丰富的词汇来描述任何事情。当我去非英语的亚洲国家时，我只是指出他们知道我的意思，因为我不会说这种语言...... 但是很难真正与他们进行愉快的交谈某人...

将 RPC 伪装成 REST 并不是一个坏主意，因为这就是整个练习。就我个人而言，我认为 SOAP 受到了抨击和憎恨，而事实上它有很多优点（以及 HTTP 压缩、HTTP/SSL 和 cookie，还有更多的优点）......而且你的应用程序确实暴露了客户端调用的方法。为什么要将它翻译成 REST？我从来没有被说服过。 SOAP 让您可以使用我们熟悉和喜爱的编程接口语言。

但要回答您的问题，将 RPC 伪装成 REST 是不是一个坏主意？不。将 RPC 伪装成 REST 并转换为四个基本操作是事情的本质。无论您认为这是否酷，都是另一回事。

【讨论】：

谢谢，我在东南亚，当你提到解释 REST 动词的容易性时，我笑了。我并不完全反对肥皂，如果有问题的 RPC 不是那么微不足道，我可能会考虑它。
这就是 SOAP 的重点：无论您使用哪种编程语言，它总是比 REST 更容易，因为它有 API。无论您使用哪种语言，您都可以将一个类标记为 SOAPy，它会自动获得一个 WSDL 等。所以琐碎是不平凡的。
REST 不仅仅是 HTTP 动词。另外，我不确定 SIAP 总是比休息更容易。当您可以使用 wget 轻松进行 SOAP 时，我会考虑这个想法。
为什么？用于调试？还是您实际上将 wget 用作您的应用程序的一部分？无论您需要弄清楚 SOAP 已经存在了一段时间，它都已经构建好了。
哦，我亲爱的上帝。如果每个人和标准都使用有限的动词，那么进入对话真的很容易。当有些人开始制作自定义词（提示提示 RPC）时，您必须学习该语言并检查您所采取的每一步的文档。在设计 API 时您看不到这一点。尝试为 20 个 REST API 和 20 个 RPC API 编写 20 个客户端，你会看到。我宁愿有一个有限但标准的动词而不是自定义词，这甚至可能会突然造成副作用。 xxxUpdateWithCareyyyy 函数会更改哪些资源？太糟糕了，你不得不问我；）