为了坚持 REST 概念，例如安全操作、幂等性等，如何实现涉及多个参数的复杂搜索操作？
我看过谷歌的实现，那是有创意的。除此之外还有什么选择？
幂等要求是让我绊倒的原因，因为该操作肯定不会针对相同的条件返回相同的结果，例如搜索名为“Smith”的客户不会每次都返回相同的集合，因为添加了更多的“Smith”客户每时每刻。我的直觉是为此使用 GET，但对于真正的搜索功能，结果似乎不是幂等的，并且由于其流动的结果集而需要标记为不可缓存。
最佳答案
换句话说，幂等性背后的基础是 GET 操作不会影响操作的结果。也就是说，GET 可以安全地重复而没有不良副作用。
但是，幂等请求与资源的表示无关。
两个人为的例子:
GET /current-time
GET /current-weather/90210
应该很明显，这些资源会随着时间而改变，一些资源的变化比其他资源更快。但是 GET 操作本身在影响实际资源方面并没有密切关系。
相比较:
GET /next-counter
显然，我希望这不是一个幂等请求。请求本身正在更改资源。
此外，没有什么可以说幂等操作没有副作用。显然，许多系统日志访问和请求，包括 GET。因此，当您执行 GET/resource 时，日志将因该 GET 而更改。这种副作用不会使 GET 不是幂等的。基本前提是对资源本身的影响。
但是怎么样，说:
GET /logs
如果日志记录了每个请求，并且 GET 以当前状态返回日志，这是否意味着这种情况下的 GET 不是幂等的？是的!真的有关系吗？没有。不适用于这种极端情况。只是游戏的本质。
关于什么:
GET /random-number
如果您使用的是伪随机数生成器，则其中大多数都是自给自足的。从种子开始，将结果反馈给自己以获得下一个数字。因此，在这里使用 GET 可能不是幂等的。但是是吗？你怎么知道随机数是如何产生的。它可能是一个白噪声源。你为什么在乎？如果资源只是一个随机数，你真的不知道操作是否正在改变它。
但仅仅因为指南可能存在异常(exception)情况，并不一定会使这些指南背后的概念无效。
资源变化，这是一个简单的生活事实。资源的表示不必是通用的，或者在请求之间保持一致，或者在用户之间保持一致。从字面上看，资源的表示是 GET 提供的，它取决于应用程序，使用谁知道什么标准来确定每个请求的表示。幂等请求非常好，因为它们可以很好地与 REST 模型的其余部分配合使用——比如缓存和内容协商。
大多数资源不会快速变化，并且依赖于特定事务，使用非幂等动词，为客户提供更可预测和一致的界面。当一个方法应该是幂等的时，当事实证明并非如此时，客户会感到非常惊讶。但最终，它取决于应用程序及其文档化界面。
关于web-services - REST 搜索接口(interface)和 GET 的幂等性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9234363/