我已经看到Google的实施,这是有创意的.什么是选择,除此之外？
因为操作肯定不会以相同的标准返回相同的结果,所以称为“史密斯”的客户将不会每次都返回相同的设置,因为添加了更多的“史密斯”客户每时每刻.我的直觉是为此使用GET,但是对于真正的搜索功能,结果似乎不是幂等的,并且由于其流体结果集需要被标记为不可缓存.
解决方法
然而,一个幂等的请求与资源的表示无关.
两个例子：
GET /current-time GET /current-weather/90210
显而易见,这些资源会随着时间的推移而改变,一些资源比其他资源变化更快.但是,GET操作本身并不会影响实际的资源.
对比：
GET /next-counter
显然我希望这不是一个幂等的要求.请求本身正在更改资源.
此外,没有任何表示幂等操作没有副作用.显然,许多系统日志访问和请求,包括GET.因此,当您执行GET /资源时,日志将作为该GET的结果而改变.这种副作用不会使得GET不是幂等的.其根本前提就是对资源本身的影响.
但是呢,说：
GET /logs
如果日志注册每个请求,并且GET将日志返回到当前状态,那意味着GET在这种情况下不是幂等的？对！真的有关系吗？不.不是为了这个边缘的情况.只是游戏的本质.
关于什么：
GET /random-number
如果您使用的是伪随机数字生成器,那么大部分都是自己提供的.从一个种子开始,并把他们的结果回馈给自己以获得下一个数字.所以在这里使用GET可能不是幂等的.但是呢你如何知道如何产生随机数.它可能是一个白噪声源.你为什么关心？如果资源只是一个随机数,你真的不知道操作是否改变了.
但只是因为这些指南可能会有例外,并不一定会使这些指南背后的概念无效.
资源变化,这是一个简单的生活事实.资源的表示不一定是通用的,或者跨请求一致,也不一定在用户之间.从字面上来说,资源的表示是GET提供的,由应用程序决定,使用谁知道什么标准来确定每个请求的表示.幂等请求是非常好的,因为它们与REST模型的其余部分工作良好 – 例如缓存和内容协商.
大多数资源不会快速变化,依赖特定的交易,使用非幂等动词,为客户提供更可预测和一致的界面.当一种方法应该是幂等的时候,当事实证明不是这样的情况时,客户将会非常惊讶.但最终,它的应用程序及其记录的界面.
