GET动词在RESTful API中的幂等性 [英] Idempotentency of GET verb in an RESTful API

查看:207
本文介绍了GET动词在RESTful API中的幂等性的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

正如这里提到的 https://restfulapi.net/http-methods/ (以及其他地方):


GET APIs应该是幂等的,这意味着多个
相同的请求必须产生相同的每次都会产生结果,直到另一个
API(POST或PUT)已经改变了服务器上的资源状态。


如何做到这一点在返回时间的API中是否为true?或者返回受时间影响的数据。

换句话说,每次我使用 GET http:// ip:port / get- time-now / ,它将返回不同的响应。然而,我没有在两个排序的 GET的之间发送任何 POST PUT $ c>



这是否使前面的陈述错误?我误解了什么?

解决方案

幂等性是对客户/中间人的承诺,即在网络故障或类似情况下可以重新发布请求考虑因素,而不是数据永远不会改变。



例如,如果您以 POST 请求为例,如果发生网络故障,您不知道以前请求到达服务器,但响应中途丢失或者初始请求根本没有到达服务器。如果你重新发出请求,你可能会创建更多的资源,因此 POST 不是幂等的。另一方的 PUT 具有合同,它将当前表示与请求中包含的表示替换。如果两次发送相同的请求,则在处理任何两个 PUT 请求之后,资源的内容应该是相同的。请注意,实际结果可能仍然不同,因为该服务可以自由地将接收到的实体修改为相应的表示。另外,在通过 PUT 发送数据并通过 GET 检索数据之间,另一个客户端可能已经更新了它们之间的状态,所以不能保证你实际上会收到你发送给服务的确切表达。

Saftiness是另一个承诺,只有 GET HEAD OPTIONS 支持。它承诺调用者不会修改任何状态,因此客户/中介在发出这样的请求时是安全的,而不必担心它会修改任何状态。在实践中,这是对抓取工具的重要承诺,它会盲目地调用任何URL来学习其内容。在违反这些承诺的情况下,即在处理 GET 请求时删除数据,唯一责备的是服务实现者而不是调用者。如果一个爬虫调用这样的URL并因此删除了一些数据,它实际上并不是爬虫的错误,而只是服务实现者。

由于您的回复中有一个动态值,可能希望防止响应缓存,但其他中介可能会为您的资源返回一个旧状态


As it was mentioned here https://restfulapi.net/http-methods/ (and in other places as well):

GET APIs should be idempotent, which means that making multiple identical requests must produce same result everytime until another API (POST or PUT) has changed the state of resource on server.

How to make this true in an API that return time for example? or that return data that is affected by time.

In other words, each time I use GET http://ip:port/get-time-now/, it is going to return a different response. However, I did not send any POST or PUT between two sequenced GET's

Does this make the previous statement wrong? Did I misunderstand something?

解决方案

Idempotency is a promise to clients/intermediaries that the request can be reissued in case of network failures or the like without any further considerations and not so much that the data will never change.

If you take a POST request for example, in case of a network failure you do not know if the previous request reached the server but the response got lost midway or if the initial request didn't even reach the server at all. If you re-issue the request you might create a further resource actually, hence POST is not idempotent. PUT on the other side has the contract that it replaces the current representation with the one contained in the request. If you send the same request twice the content of the resource should be the same after any of the two PUT requests was processed. Note that the actual result can still differ as the service is free to modify the received entity to a corresponding representation. Also, between sending the data via PUT and retrieving it via GET a further client could have updated the state in between, so there is no guarantee that you will actually receive the exact representation you've sent to the service.

Saftiness is an other promise that only GET, HEAD and OPTIONS supports. It promises the invoker that it wont modify any state at all hence clients/intermediaries are safe on issuing such request without having to fear that it will modify any state. In practice this is an important promise to crawlers which blindly invoke any URLs in order to learn their content. In case of violating such promises, i.e. by deleting data while processing a GET request the only one to blame is the service implementor but not the invoker. If a crawler invokes such URLs and hence removes some data it is not the crawlers fault actually but only the service implementor.

As you have a dynamic value in your response, you might want to prevent caching of responses though as otherwise intermediaries might return an old state for your resource

这篇关于GET动词在RESTful API中的幂等性的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆