为了坚持REST概念，例如安全操作，幂等性等，如何实现涉及多个参数的复杂搜索操作？
我看过谷歌的实施，这很有创意。什么是选项，除此之外？
幂等要求就是绊倒我，因为操作肯定不会为相同的标准返回相同的结果，比如搜索名为“Smith”的客户每次都不会返回相同的设置，因为更多的“史密斯”客户一直在增加。我的直觉是为此使用GET，但对于真正的搜索功能，结果似乎不是幂等的，并且由于其流畅的结果集而需要被标记为不可缓存。
答案 0 :(得分：23)
换句话说，幂等性背后的基础是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可能不是幂等的。但是吗？你怎么知道如何生成随机数。它可能是白噪声源。你为什么关心？如果资源只是一个随机数，你真的不知道该操作是否正在改变它。
但仅仅因为指南可能存在例外情况，并不一定会使这些指导原则背后的概念失效。
资源变化，这是一个简单的生活现实。资源的表示不必是通用的，或者在请求之间保持一致，或者在用户之间保持一致。从字面上看，资源的表示是GET提供的，并且取决于应用程序，使用谁知道确定每个请求的表示的标准。幂等请求非常好，因为它们可以很好地与REST模型的其余部分一起使用 - 比如缓存和内容协商。
大多数资源不会快速更改，并且依赖于使用非幂等动词的特定事务，可为客户端提供更可预测且一致的界面。当一个方法被认为是幂等的时候，当事实证明不是这样时，客户会非常惊讶。但最终，它取决于应用程序及其记录的界面。
答案 1 :(得分：9)
正确实施后，GET是安全且幂等的。这意味着：
不上面说的是对同一URI的GET始终返回相同的数据。
GET导致每次都执行相同的服务器端功能，该功能通常是“返回所请求资源的表示”。如果该资源自上次GET以来已更改，则客户端将获取最新数据。服务器执行的函数是幂等性的来源，而不是它用作输入的数据（所请求资源的状态）。
如果在URI中使用时间戳以确保每次请求的服务器数据相同，那只意味着已经是幂等的（实现GET的函数）将对相同的数据起作用，从而保证每次都是相同的结果。
答案 2 :(得分：2)
对于同一数据集，它将是幂等的。您可以使用时间戳过滤器实现此目的。