在restful web服务的上下文中,对get方法产生副作用是否可以接受?
例如一次性下载链接

GET /downloads/664d92b3-b373-4dac-a4fb-7a41d015109a

在下一次请求时将返回200和“东西”以及404。
http规范指出get方法应该是安全的,并且根据https://tools.ietf.org/html/rfc7231#section-4.2.1
如果请求方法的定义语义是
本质上是只读的;即,客户端不请求
不需要,源服务器上的任何状态更改都是由于
对目标资源应用安全方法。

安全方法的这个定义并不阻止实现
包括潜在有害的行为
完全只读,或者在调用safe时导致副作用
方法。然而,重要的是,客户没有
要求额外的行为并且不能被追究责任
它。
提供了几个明确的例子,使我认为不允许使用安全的方法故意删除资源。
例如,大多数服务器将请求信息附加到访问
在每个响应完成时记录文件,而不管
方法,即使日志存储可能
已满并使服务器崩溃。
以及
同样,一个安全的请求被启动
在网上选择一个广告往往会有
收取广告费的效果。
以及
例如,它是
基于Web的内容编辑软件使用
查询参数,如“page”?do=删除”。如果这样做的目的
资源将执行不安全的操作,则资源所有者必须
当使用保险箱访问该操作时,禁用或禁止该操作
请求方法。
单用链接显然是现实。我只是想知道他们是在滥用规范还是我不明白。
有一个意见是很好的,但工作在这些规格和理解他们的微妙之处将是最令人信服的。

最佳答案

你的建议在某些情况下是可以接受的,不一定是对规范的滥用。
首先,2616关于安全方法,他们说:
不应该有采取行动的意义
检索
以及短语“不应该”is defined as follows(强调的是):
这个短语或“不推荐”的意思是
在特定情况下存在特殊原因
行为是可以接受甚至有用的,但是
应该被理解并且在之前仔细权衡过这个案子
实现用此标签描述的任何行为。
你链接到的新版本(我认为它取代了2616)没有使用“不应该”这个词,但是他们也没有用“不应该”来代替它。他们还承认,只要客户不负责任,就不排除副作用。所以我认为安全方法的想法是一样的。
既然规范承认有些情况下是可以的,那么我们如何知道你的情况是否如此——更重要的是,我们如何在规范的“精神”范围内,即确保我们没有滥用它?
我想引用这段引自7231的话:
区分安全方法和不安全方法的目的是
允许自动检索进程(spider)和缓存性能
优化(预取)工作而不担心造成伤害。
如果你的应用程序是一个私有的内部网应用程序,并且你不关心这里提到的问题,你的方法是可以的。换一种方式:考虑到所有可能发生get的方式,你能接受这种副作用吗?
在宁静的指导下工作并不总是坏事。重要的是要确保你了解它的影响。
尽管如此,如果您正在寻找一种通过http实现可靠、一致的一次性资源交付的方法,那么很值得阅读bill de h_ra的httplr规范(http://www.dehora.net/doc/httplr/draft-httplr-01.html)。这种方法依赖于客户机确认收到消息。您可能可以使用类似的方法来允许不知道一次性使用策略(spider等)的此用户代理获取资源而不会造成副作用,但仍然允许参与的客户端在一次获取后导致资源不可用。
像这样的事务性方法还有一个额外的好处,就是允许客户机根据需要经常重新尝试下载。这一点很重要,因为否则服务器无法知道客户端是否成功接收到消息。
如果您真的需要从服务器端为任何可能的用户代理强制执行一次性策略,那么您最初的方法可能是最好的,但请记住,它实际上是一个“最多一次”策略。

关于rest - 一次性下载链接是否符合HTTP规范?,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/46003887/

10-12 12:43
查看更多