REST搜索接口和GET的幂等性

Question

为了坚持REST概念，如安全操作、幂等性等，如何实现涉及多个参数的复杂搜索操作？

我看过谷歌的实现，这很有创意。除此之外，还有什么选择呢？

幂等要求是让我犯错的原因，因为对于相同的条件，操作肯定不会返回相同的结果，比如搜索名为"Smith“的客户不会每次都返回相同的集合，因为一直都会添加更多的"Smith”客户。我的直觉是使用GET，但对于真正的搜索功能，结果似乎不是幂等的，并且由于其流畅的结果集，需要将其标记为不可缓存。

Answer 1

换句话说，幂等性背后的基本原理是GET操作不会影响操作的结果。也就是说，可以安全地重复GET，而不会产生不良的副作用。

但是，幂等请求与资源的表示无关。

两个人为的例子：

GET /current-time

GET /current-weather/90210

很明显，这些资源会随着时间的推移而变化，有些资源的变化比其他资源变化得更快。但是GET操作本身并不影响实际的资源。

对比：

GET /next-counter

显然，我希望这不是一个幂等的请求。请求本身正在更改资源。

此外，也没有什么能说明幂等运算没有副作用。显然，许多系统日志访问和请求，包括GET。因此，当您获取/resource时，日志将因该GET而更改。这种副作用并不会使GET不是幂等的。其基本前提是对资源本身的影响。

但是，比如说：

GET /logs

如果日志注册了每个请求，并且GET返回当前状态的日志，这是否意味着这种情况下的GET不是幂等的？是啊！这真的很重要吗？不是的。对于这个边缘情况不是这样的。这就是游戏的本质。

下面是什么：

GET /random-number

如果您使用的是伪随机数生成器，那么这些生成器中的大多数都是自动生成的。从一个种子开始，并将结果反馈给自己，以获得下一个数字。因此，在这里使用GET可能不是幂等的。但这是真的吗？你怎么知道随机数是如何产生的。可能是白噪声源。你干嘛这么在意？如果资源只是一个随机数，你真的不知道操作是否改变了它。

但是，仅仅因为指南中可能有例外，并不一定会使这些指南背后的概念失效。

资源是变化的，这是一个简单的生活事实。资源的表示不必是通用的，或者在请求之间保持一致，或者在用户之间保持一致。从字面上讲，资源的表示是GET提供的，它取决于应用程序，使用谁知道什么标准来确定每个请求的表示。幂等请求非常好，因为它们与rest模型的其余部分工作得很好--比如缓存和内容协商。

大多数资源不会快速变化，并且依赖于特定的事务，使用非幂等动词，为客户端提供了更可预测和一致的接口。当一个方法被认为是幂等的，当它被证明不是这样的时候，客户会非常惊讶。但最终，这取决于应用程序和它的文档化接口。

Answer 2

如果实现得当，GET是安全和幂等的。这意味着：

1. 它不会对服务器端产生任何客户端可见的副作用当它指向相同的URI时，它会导致每次都执行相同的服务器端函数，无论它被发出多少次，或者何时

上面没有提到的是，GET到相同的URI总是返回相同的数据。

GET导致每次执行相同的服务器端函数，该函数通常是“返回所请求资源的表示”。如果该资源在上次GET之后发生了更改，则客户端将获取最新数据。服务器执行的函数是幂等性的来源，而不是它用作输入的数据(请求的资源的状态)。

如果在URI中使用时间戳来确保每次请求的服务器数据都是相同的，这只是意味着已经是幂等的东西(实现GET的函数)将作用于相同的数据，从而保证每次都有相同的结果。

Answer 3

对于相同的数据集，它将是幂等的。您可以使用时间戳过滤器来实现这一点。