8

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

我们正在考虑做的是这样的：

发布 /index_updates

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

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

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

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

有没有人有意见或建议？

谢谢，

克里斯

4

3 回答 3

5

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

于 2008-12-22T09:43:33.263 回答
4

您可能从 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>
于 2009-04-09T15:43:39.827 回答
-2

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

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

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

于 2008-12-22T19:25:05.053 回答