2

这似乎是一个非常基本的问题，如果之前有人问过这个问题，我们深表歉意；请指出任何有用资源的方向。

所以我有一个 RESTful 服务来检索一些数据。但是，RESTful 服务需要一定数量的数据才能进行检索。该数据可以粗略地概括为“用户上下文”数据——服务需要使用该信息来执行检索的有关用户的信息（无论是由调用应用程序存储还是先前从另一个应用程序检索）。

由于 REST 在语义上工作，因此检索某些内容的正确动词（HTTP 方法）是 GET 请求。我见过的大多数示例 GET 请求只使用少量数据，并且数据通过 URL 传递。但是，一旦我们进入需要大量数据来进行检索的服务领域，将所有这些信息都放在 URL 中似乎是错误的。不仅如此，某些组件（通常是 255 个字符左右，IIRC）对 URL 长度有已知的限制。

似乎可用的选项是：

  • 使用 POST 在请求正文中发送数据。但是，这不是语义，因为我们没有要求服务更新任何内容，只是检索。
  • 将大部分信息（在我的例子中是“用户上下文”）放入 HTTP 标头中。但是，这“感觉不对”，因为标题应该用于标题，而不是数据。
  • 发出多个请求以在多个 URL 中发送数据。然而，这似乎打破了无状态的目标，因为服务必须保持某种状态才能将请求捆绑在一起。
  • 将数据写入数据库，然后将密钥传递给服务以从那里检索数据。然而，这将导致请求不是自包含的，并且还会引入性能瓶颈。

还有其他选择吗？这里的最佳做法是什么？

4

1 回答 1

2

虽然不受规范限制，但 HTTP 标头（如请求路径 (URL)）确实具有有限的长度（请参见下面的链接）。

您可以调整或删除服务器限制，但这样会更难与第 3 方系统（例如 HTTP 缓存）保持兼容，并且也无法保证任意 HTTP 客户端都支持超过这些事实上的限制。

向服务器兼容地发送任意大量数据的唯一方法是通过请求正文；在标准 HTTP 动词中，只有 POST 和 PUT 请求可能有正文，其中，PUT 在语义上与您尝试完成的内容不兼容。

除非您可以保证所有必要的信息将始终适合 URL 或请求标头（考虑到上述限制），否则您应该设计您的 REST API 以通过 POST 请求来表达这种需求。

认为 POST 动词仅用于在服务器上修改或创建某些内容是一种误解。真的，只是其他动词是幂等的（没有副作用，并且执行重复请求会产生重复的结果），因此 POST 是唯一可以满足这些需求的动词，但总的来说，POST 是一个包罗万象的对于其他动词做得不好的任何事情。

当 GET 的限制无法解决时，POST 可以合法地用作检索（更多导致重定向）或处理动词。Cache-Control通过设置与缓存相关的响应标头（例如和），也可以使 POST 响应的行为更像 GET Expires。

于 2015-01-09T21:02:24.607 回答