Web服务 – REST搜索界面和GET的幂等
|
为了遵守诸如安全操作,幂等的REST概念,如何实现涉及多个参数的复杂搜索操作？
我已经看到Google的实施,这是有创意的.什么是选择,除此之外？ 因为操作肯定不会以相同的标准返回相同的结果,所以称为“史密斯”的客户将不会每次都返回相同的设置,因为添加了更多的“史密斯”客户每时每刻.我的直觉是为此使用GET,但是对于真正的搜索功能,结果似乎不是幂等的,并且由于其流体结果集需要被标记为不可缓存. 解决方法
换句话说,幂等于背后的基础是GET操作不会影响操作的结果.也就是说,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模型的其余部分工作良好 – 例如缓存和内容协商. 大多数资源不会快速变化,依赖特定的交易,使用非幂等动词,为客户提供更可预测和一致的界面.当一种方法应该是幂等的时候,当事实证明不是这样的情况时,客户将会非常惊讶.但最终,它的应用程序及其记录的界面. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |