为了坚持REST概念(例如安全操作，幂等)，如何实现涉及多个参数的复杂搜索操作？
我看过Google的实现，这很有创意。除此之外，还有什么选择？
幂等的要求使我感到震惊，因为对于相同的条件，该操作绝对不会返回相同的结果，例如，搜索名为“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模型配合使用，例如缓存和内容协商。
大多数资源不会快速改变，并且依赖于使用非幂等动词的特定事务为客户提供了更加可预测和一致的界面。当一种方法被认为是幂等的时，事实证明事实并非如此，客户会感到非常惊讶。但最后，取决于应用程序及其文档化的接口(interface)。
关于web-services - REST搜索界面和GET的幂等性，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/9234363/