REST 搜索接口和 GET 的幂等性 [英] REST search interface and the idempotency of GET

问题描述

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

In order to stick with the REST concepts, such as safe operations, idempotency, etc., how can one implement a complex search operation involving multiple parameters?

我已经看到了 Google 的实施，这很有创意.除此之外还有什么选择?

I have seen Google's implementation, and that is creative. What is an option, other than that?

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

The idempotent requirement is what is tripping me up, as the operation will definitely not return the same results for the same criteria, say searching for customers named "Smith" will not return the same set every time, because more "Smith" customer are added all the time. My instinct is to use GET for this, but for a true search feature, the result would not seem to be idempotent, and would need to be marked as non-cacheable due to its fluid result set.

推荐答案

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

To put it another way, the basics behind idempotency is that the GET operation doesn't affect the results of the operation. That is, the GET can safely be repeated with no ill side effects.

然而，幂等请求与资源的表示无关.

However, an idempotent request has nothing to do with the representation of the resource.

两个人为的例子:

GET /current-time

GET /current-weather/90210

显而易见，这些资源会随着时间的推移而变化，有些资源的变化速度比其他资源快.但 GET 操作本身与影响实际资源没有密切关系.

As should be obvious, these resources will change over time, some resources change more rapidly than others. But the GET operation itself is not germane in affecting the actual resource.

对比:

GET /next-counter

显然我希望这不是幂等请求.请求本身正在改变资源.

This is, obviously I hope, not an idempotent request. The request itself is changing the resource.

此外，没有任何内容表明幂等操作没有副作用.显然，许多系统日志访问和请求，包括 GET.因此，当您执行 GET/resource 时，日志将因该 GET 而更改.这种副作用不会使 GET 不是幂等的.根本前提是对资源本身的影响.

Also, there's nothing that says an idempotent operation has NO side effects. Clearly, many system log accesses and requests, including GETs. Therefore, when you do GET /resource, the logs will change as a result of that GET. That kind of side affect doesn't make the GET not idempotent. The fundamental premise is the affect on the resource itself.

但是呢，比如说:

GET /logs

如果日志注册了每个请求，并且 GET 返回当前状态的日志，这是否意味着在这种情况下 GET 不是幂等的?是的！真的有关系吗?不.不适用于这种边缘情况.只是游戏的性质.

If the logs register every request, and the GET is returning the logs in their current state, does that mean that the GET in this case is not idempotent? Yup! Does it really matter? Nope. Not for this one edge case. Just the nature of the game.

关于:

GET /random-number

如果您使用的是伪随机数生成器，那么大多数生成器都会以自己为食.从种子开始，并将结果反馈给自己以获得下一个数字.因此，在这里使用 GET 可能不是幂等的.但是是吗?你怎么知道随机数是怎么产生的.它可能是白噪声源.你为什么关心?如果资源只是一个随机数，你真的不知道操作是否在改变它.

If you're using a pseudo-random number generator, most of those feed upon themselves. Starting with a seed and feeding their results back in to themselves to get the next number. So, using a GET here may not be idempotent. But is it? How do you know how the random number is generated. It could be a white noise source. And why do you care? If the resource is simply a random number, you really don't know if the operation is changing it or not.

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

But just because there may be exceptions to the guidelines, doesn't necessarily invalidate the concepts behind those guidelines.

资源变化，这是生活中的一个简单事实.资源的表示不必是通用的，或跨请求一致，或跨用户一致.从字面上看，资源的表示就是 GET 提供的内容，这取决于应用程序，谁知道使用什么标准来确定每个请求的表示.幂等请求非常好，因为它们可以与 REST 模型的其余部分很好地协同工作——比如缓存和内容协商.

Resources change, thats a simple fact of life. The representation of a resource does not have to be universal, or consistent across requests, or consistent across users. Literally, the representation of a resource is what GET delivers, and it is up to the application, using who knows what criteria to determine that representation for each request. Idempotent requests are very nice because they work well with the rest of the REST model -- things like caching and content negotiation.

大多数资源不会快速变化，依赖于特定事务，使用非幂等动词，为客户端提供更可预测和一致的界面.当一个方法应该是幂等的，当事实并非如此时，客户会非常惊讶.但最终取决于应用程序及其文档化界面.

Most resources don't change quickly, and relying on specific transactions, using non-idempotent verbs, offers a more predictable and consistent interface for clients. When a method is supposed to be idempotent, clients will be quite surprised when it turns out to not be the case. But in the end, its up to the application and its documented interface.

这篇关于REST 搜索接口和 GET 的幂等性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！