REST搜索界面和GET的幂等性

Pit*_*DBA 10 rest web-services

为了坚持REST概念,例如安全操作,幂等性等,如何实现涉及多个参数的复杂搜索操作?

我看过谷歌的实施,这很有创意.什么是期权,除此之外?

幂等要求就是绊倒我,因为操作肯定不会为相同的标准返回相同的结果,比如搜索名为"Smith"的客户每次都不会返回相同的结果,因为添加了更多的"Smith"客户每时每刻.我的直觉是使用GET,但对于真正的搜索功能,结果似乎不是幂等的,并且由于其流畅的结果集需要被标记为不可缓存.

Wil*_*ung 24

换句话说,幂等性背后的基础是GET操作不会影响操作的结果.也就是说,GET可以安全地重复,没有副作用.

但是,幂等请求与资源的表示无关.

两个人为的例子:

GET /current-time

GET /current-weather/90210
Run Code Online (Sandbox Code Playgroud)

显而易见,这些资源会随着时间的推移而发生变化,某些资源的变化速度会快于其他资源.但是GET操作本身并没有影响实际资源.

相比较:

GET /next-counter
Run Code Online (Sandbox Code Playgroud)

显然,我希望这不是一个幂等的要求.请求本身正在改变资源.

此外,没有任何内容表明幂等操作没有副作用.显然,许多系统日志访问和请求,包括GET.因此,当您执行GET/resource时,日志将因GET而更改.这种副作用并不能使GET不是幂等的.基本前提是对资源本身的影响.

但是,说:

GET /logs
Run Code Online (Sandbox Code Playgroud)

如果日志记录每个请求,并且GET以当前状态返回日志,这是否意味着在这种情况下GET不是幂等的?对!真的有关系吗?不.不适用于这一个边缘案例.只是游戏的本质.

关于什么:

GET /random-number
Run Code Online (Sandbox Code Playgroud)

如果您使用的是伪随机数生成器,那么大多数生成器都会自行处理.从种子开始,将结果反馈给自己以获得下一个数字.因此,在这里使用GET可能不是幂等的.但是吗?你怎么知道如何生成随机数.它可能是白噪声源.你为什么关心?如果资源只是一个随机数,您实际上不知道操作是否正在改变它.

但仅仅因为指南可能存在例外情况,并不一定会使这些指导原则背后的概念无效.

资源变化,这是一个简单的生活现实.资源的表示不必是通用的,或者在请求之间保持一致,或者在用户之间保持一致.从字面上看,资源的表示是GET提供的,并且取决于应用程序,使用谁知道确定每个请求的表示的标准.幂等请求非常好,因为它们可以很好地与REST模型的其余部分一起使用 - 比如缓存和内容协商.

大多数资源不会快速更改,并且依赖于使用非幂等动词的特定事务,为客户端提供了更可预测和一致的接口.当一个方法被认为是幂等的时候,当事实证明不是这样时,客户会非常惊讶.但最终,它取决于应用程序及其记录的界面.


Bri*_*lly 9

正确实施GET是安全和幂等的.这意味着:

  1. 它将导致服务器端没有客户端可见的副作用
  2. 当指向相同的URI时,它会导致每次执行相同的服务器端功能,无论它发出多少次,或者何时

什么是不是上面说的是GET相同的URI总是返回相同的数据.

GET导致每次都执行相同的服务器端功能,并且该功能通常是" 返回所请求资源的表示 ".如果该资源自上次GET以来已更改,则客户端将获取最新数据.服务器执行的功能是幂等性的来源,而不是它用作输入的数据(被请求的资源的状态).

如果在URI中使用时间戳以确保每次请求的服务器数据相同,那只意味着已经是幂等的(实现GET的函数)将对相同的数据起作用,从而保证相同的结果每一次.