使用 *many* 参数调用 RESTful 服务答案

【问题标题】：Calling a RESTful service with *many* parameters使用 *many* 参数调用 RESTful 服务
【发布时间】：2010-10-01 17:40:15
【问题描述】：

我们正在设计一个 iPhone 应用程序，它将回调在 Tomcat 中运行的 RESTful 服务。我们需要发送许多查询参数，并且已经超过了手机允许的最大值。

使用带有参数的 PUT 调用是否是 RESTful 的，即使其意图不在于修改服务器？ POST 似乎不正确，因为它不是幂等的，而 PUT 是（因此更类似于 GET 的行为）。

谢谢。

【问题讨论】：

REST 的原则和精神比你的产品重要得多。因此，您的产品不应该存在。
@Mark：好点。如果不能遵循法律的精神，就停止发展！为什么我没有想到呢？我现在打电话给我的老板，告诉他这个疯狂的数据模型不符合 Chen 所阐述的原始关系模型，我们真的应该停止工作。太棒了！
@S.Lott：我们遇到了 iPhone 的限制（正如我在最初的问题中所说的那样）。
@Aliostad：为什么重要？如果参数是 XML 或 JSON，我们可以在 GET 的正文中发送参数吗？
只是为了感兴趣你的URI有多大或iphone的限制是多少？极长的 URI 可能是一种设计气味。为什么这么大？是参数的数量还是参数值的大小？

标签： rest

【解决方案1】：

您有三个最大程度地符合 HTTP 的选项：

首先，您可以选择以某种方式压缩发送参数以形成更短的 URL。

其次，GET 并没有说明您无法在请求中发送消息正文，无论您选择什么Content-Type 或-Length。并非所有服务器都支持这一点，但 HTTP 协议本身支持。

第三，您可以将参数发布到/queries/ 资源，并在Location 响应标头中使用201 Created 和新URL（如/queries/78a65g82）进行响应，然后客户端调用@987654328 @ on（重复，或者甚至在Ranges，如果这是一个好处）来检索结果。

【讨论】：

我想你可能会发现一些代理不会转发 GET 请求的正文。
像 Darrel set 一样，您不应该传递 GET 消息有效负载，它可以在您的开发设置中工作，但可能会在您的产品设置中崩溃。它太不可靠了，而且路由（以及所涉及的代理）通常不受您的控制。
+1 表示 /queries/78a65g82 建议，这是我们使用的。
不幸的是，这使得您的系统的可扩展性大大降低，因为您需要存储此状态（并在故障转移情况下在多个实例之间共享它）——您基本上不再是无状态的。还有一个问题是这个状态应该被存储多长时间以及发出两个请求的开销（因为需要额外的往返会减慢用户体验）。这也很愚蠢，因为第一个响应可能包含完整的答案，因为已知所有信息都可以满足它。

【解决方案2】：

如果你想要它是 RESTful 的，你可以这样做：将参数放到服务器（在你选择的位置），或者你可以发布它们并让服务器为你放置它们。无论哪种方式，您都刚刚创建了一个包含所需参数的资源。然后您发送一个 GET 引用该特定资源。因此，在回答您的 GET 时，服务器知道从何处获取大量参数。那将是 RESTful。

但是，如果您可以对单个请求执行相同的操作，那么发送两个请求并不是很有效。我只是尽量务实。

考虑一下：PUT 告诉代理它们不应该缓存响应，但是重试（通过任何基础设施元素）绝对是可能的，因为它是幂等的（就像 GET 一样）。 GET 比 PUT 能给你什么？响应可以被缓存。但是有了这么多参数，我会假设大多数请求都是唯一的，对吧？因此，缓存不会经常带来太多回报。因此，使用 PUT 似乎是务实的，也是正确的选择。

【讨论】：

正如我在之前的评论中所说，我们有很多参数的原因是每个参数都是 iPhone 上已有记录的 ID。我们试图避免在刷新时重新发送这些记录。您关于不缓存和唯一性的评论是恰当的。

【解决方案3】：

违背了 REST 的精神，但如果行得通，就要务实。

【讨论】：

有没有 RESTful 的方式来做到这一点？我不是法律条文（或本案中的规范）的坚持者，但如果有办法，我想遵循标准。