10

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

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

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

在这些情况下，似乎有必要将数据发布到服务器，但结果不会是变化，只是信息。发布图像，接收服务器上存在的相似图像列表。

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

编辑

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

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

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

  1. 客户端：发布一个临时资源
  2. 服务器：使用临时资源 URI 和 TTL 标头 (?) 进行响应。用资源 URI 以外的东西进行响应是不安的——对吗？
  3. 客户端：在 TTL 时间内获取临时资源
  4. 服务器在 TTL 后删除资源

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

4

2 回答 2

6

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

最重要的是您的客户可以合理地猜测 您的 API 的行为方式。可以明确记录诸如使用 POST 而不创建资源的图像搜索之类的异常，以供他们注意。

于 2014-01-31T08:42:37.277 回答
4

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

于 2014-01-31T08:45:47.940 回答