RESTful：什么时候可以发布而不在服务器上创建资源？答案

【问题标题】：RESTful: When is it OK to POST without creating a resource on server?RESTful：什么时候可以发布而不在服务器上创建资源？
【发布时间】：2014-01-31 05:58:50
【问题描述】：

根据 REST 原则，我理解到服务器的所有 POST 都应该用于创建资源；修改服务器上的某些内容。如果要获取信息，请使用 GET。

但是对于需要发送大量信息来获取资源的情况呢？

例如，对于 URL 来说太长的复杂搜索参数。或者，假设您想发送要搜索的图像，例如 OCR 或类似的图像比较。

在这些情况下，似乎需要将数据POST到服务器，但结果不会是变化，只是信息。 POST 一张图片，接收服务器上存在的相似图片列表。

我不想构建违反这些原则的 REST API，除非它们实际上不违反。

编辑

到目前为止，似乎所有答案都是正确的（！）：Sergio 和 Kay 关于在需要时“改变规则”的实际价值是正确的。但是 uriDium 有一个好处：

上传图片实际上会导致服务器发生变化：有一个新文件，虽然是临时的。可以将复杂的搜索视为“文档”。

我想我们可以考虑“临时”更改的概念，“临时 POST”，其中服务器发生更改并产生新的临时资源。在这种情况下，出于 RESTful 的考虑，这可能是以下行为：

客户端：发布一个临时资源
服务器：使用临时资源 URI 和 TTL 标头 (?) 进行响应。使用资源 URI 以外的内容进行响应会让人不安——对吧？
客户端：在 TTL 时间内获取临时资源
服务器在 TTL 后删除资源

我会考虑在步骤 2 中使用完整的临时资源进行响应并在那里结束交互，只是为了反抗:-)

【问题讨论】：

“有些规则可以弯曲，有些可以打破”。
这不像是某个地方有一个 REST 委员会，会说“不，你不应该在这里发帖。我们不允许你的应用程序上市”。运用你的常识。
（顺便说一句，这是对“矩阵”的引用）:)

标签： rest methods principles

【解决方案1】：

当技术限制（例如，使用 HTTP get 和最大大小查询字符串，base64 编码限制为 2048）阻碍您增加业务价值（需要能够比较或搜索您的服务中的图像）由于架构方法（RESTful Web 服务）我想说您可以打破一些您试图维护的规则或原则。

最重要的是您的客户可以合理地猜测 您的 API 的行为方式。可以明确记录以供他们注意，使用 POST 进行图像搜索等例外情况。

【讨论】：

图片搜索可能是个坏例子。在这种情况下，最有可能的图像将使用 POST 上传，然后在最后一个块 GET 请求之后将提供搜索结果。不好，除非你是对的
嗯，这就是 user2020565 给出的例子。

【解决方案2】：

例如，如果您要为搜索提交参数，则可以使用 POST 在服务器上创建新的搜索请求。然后在您完成使用您在服务器上创建的搜索参数对象中的 ID 执行 GET 之后。这与 RESTful 方法保持一致

【讨论】：