RPC伪装成REST是一个不好的想法吗？

Question

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

我们正在考虑的是：

POST /index_updates 123 这本身没有问题，但问题在于已创建的资源并没有返回新创建资源的URL，例如/index_updates/1234，我们无法通过GET访问它。

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

因此，我的问题是RESTfulness是体现在结构还是意图上。我觉得我所概述的结构是restful的，但意图却不是。

有人有任何评论或建议吗？

谢谢，

Chris

- ChrisInCambo

Answer 1

使用适合的工具来完成工作。在这种情况下，正确的工具显然是纯远程过程调用（RPC），没有必要假装它是REST。

- Matthew Flaschen

---

同意，但REST对我们办公室来说是新的，从操作到资源的思维转变正在证明是困难的。我想暂时避免将RPC over HTTP引入混合中，因为这可能会打开开发人员回退到更容易掌握的RPC的大门。 - ChrisInCambo

在我看来，解决方法是将其视为机遇，而非“滑坡”。请解释为什么这是使用远程过程调用（RPC）的合适情况以及为什么您的通用架构使用REST。两者并不冲突。 - Matthew Flaschen

没错，这也是我现在所考虑的，我认为我们不需要SOAP的复杂性，只需要简单的HTTP RPC调用，并清楚地向每个人解释为什么在这种情况下使用RPC，而不是逃避或试图隐藏这一事实。做得好。 - ChrisInCambo

Answer 2

你可能会从 POST /index_updates 调用中返回一个新的资源标识符来监控操作的状态。

POST /index_updates
<contentId>123</contentId>

201 Created
Location: /index_updates/a9283b734e

获取 /index_jobs/a9283b734e

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

- Mark Renouf

---

好主意，这是一个较长的操作，因此拥有状态详情会很有用。 - ChrisInCambo

在我看来，如果您不希望在新资源上公开任何动词，那么POST请求不必返回新位置。甚至在/index_updates/123上为所有动词返回405状态码也可能是一种解决方案。 - Martijn Laarman

Answer 3

这显然是一个主观领域，但 GET PUT POST DELETE 已经足够丰富，可以描述任何东西。当我去非英语为母语的亚洲国家时，我只需要指着东西，他们就知道我的意思，因为我不会说这种语言……但是，和人进行一次很好的对话确实有些难度。

将 RPC 伪装成 REST 并不是个坏主意，因为这是整个练习的重点。个人认为，SOAP 被抨击和憎恨了，而事实上它有很多优点（还有 HTTP 压缩、HTTP/SSL 和 cookies，更多的优点）……你的应用程序真正暴露了客户端调用的方法。为什么要将其翻译为 REST 呢？我从来没有被说服过。SOAP 让我们使用我们所知道和喜爱的编程接口语言。

但是回答你的问题，将 RPC 伪装成 REST 是一个坏主意吗？不是的。将 RPC 伪装成 REST 并翻译成四个基本操作正是这个事情的关键。你是否认为这很酷是另外一回事。

- Daniel Rosenstark

---

谢谢，我在东南亚，所以当你提到解释REST动词的简便性时微笑了。我并不完全反对SOAP，如果涉及的RPC不是那么琐碎，我可能会考虑使用它。 - ChrisInCambo

这就是SOAP的优点：无论你使用什么编程语言，它总是比REST更容易，因为有API可用。无论你使用哪种语言，你都可以将一个类标记为SOAPy，它将自动获得WSDL等。所以微不足道的事情也是非微不足道的。 - Dan Rosenstark

REST不仅仅是HTTP动词。同时，我不确定SIAP总是比REST更简单。当您可以轻松使用wget进行SOAP时，我会考虑那个想法。 - Jonathan Arkell

为什么？用于调试吗？还是您实际上将wget作为应用程序的一部分使用？无论您需要弄清楚SOAP，因为它已经存在一段时间了。 - Dan Rosenstark

哦，我的天啊。如果每个人都使用有限的动词和标准语言，那么参与对话就真的很容易。但是当一些人开始制定自定义单词（暗示RPC），你就必须学习这种语言，并为每一步检查文档。在设计API时，你看不到这一点。尝试为20个REST API和20个RPC API编写20个客户端，你就会发现这一点。我宁愿有一个有限但标准的动词，而不是可能会突然引起副作用的自定义单词。 xxxUpdateWithCareyyyy函数改变了哪些资源？太糟糕了，你得问我 ;) - EralpB

谢谢@EralpB。我相信我们在这方面是一致的。你说我们应该限制自己只使用这四个基本动词，而我建议从RPC转换到REST将迫使我们达到这个目标。不是吗？ - Dan Rosenstark