我正在努力了解REST.在REST下,GET不能在服务器上触发事务性事务(这是每个人都同意的定义,它是REST的基础).
所以,想象一下你有一个网站就像 stackoverflow.com(我说的喜欢,所以如果我有这么错了,它不会改变任何东西我的问题的底层细节),其中每次有人读一个问题,使用GET,也就是一些显示"此问题已被阅读256次".
现在有人读了那个问题.计数器现在是257.GET 是事务性的,因为视图的数量增加了,现在又增加了."数量的视图"在数据库中递增,没有争论(例如,在SO上,始终显示任何问题被查看的时间).
那么,REST GET是否与网站中任何类似"视图数量"的功能根本不兼容？
因此,如果SO主页停止显示使用GET访问的纯HTML链接或停止显示"此问题已被查看x次",那么它应该是"RESTFUL"吗？
因为增加DB中的计数器是事务性的,因此"不稳定"？
编辑只是为了人们谷歌搜索这可以获得一些指示:
来自http://www.xfront.com/REST-Web-Services.html:
4.通过HTTP GET可访问的所有资源都应该是无副作用的.也就是说,请求应该只返回资源的表示.调用资源不应导致修改资源.
现在对我来说,如果表示包含"视图数量",它就是资源的一部分[并且在SO中"问题的数量"是一个非常重要的信息]并且访问它肯定会修改资源.
这与您可以在Amazon S3资源上创建的真实RESTFUL HTTP GET形成鲜明对比,在这种情况下,您的GET保证不会修改您获得的资源.
但后来我仍然很困惑.
重要的是,从客户的角度来看,GET是安全的(没有副作用),因此客户可以安全地多次调用GET而不考虑可能产生的任何副作用.
服务器的作用是服务器的责任.在视图计数器的情况下,如果服务器认为计数器的更新是副作用,则必须做出决定.通常它不会,因为计数器首先是资源语义的一部分.
但是,服务器可能决定不为某些请求增加计数器,例如爬虫的GET.
一月
IMO避免GET请求中的统计信息更新,因为"有人这么说"是关于ReST的教条.做什么是务实的.如果这涉及在响应GET请求时更新计数器,那就这样吧.
进一步详细说明,真正重要的(以及建议的原因)是,当消费者意图阅读时,消费者访问的资源不会以任何方式更新或更改.但是,更新其他数据,特别是日志和统计信息等内容不是问题.简而言之,读取资源不应该对正在读取的资源产生副作用.
编辑:要回答你的自增量计数器的情况,问问自己你应用的上下文是什么.显然,如果你定义一个名为counterThatIncrementsItselfWhenBeingRead的资源,那么它可以:
打破ReSTfulness因为读取递增计数器是一个自相矛盾的资源,如果唯一的规则是GET永远不会有副作用,或者
在给定不同的上下文时可以很好,例如,您需要将非常短的资源寿命考虑在内,并选择将增量视为在您阅读资源之后发生的事情(或更一般地在资源所有者的压缩下)
无论您选择应用哪种解决方案,问题都在于预期的行为.IMO,一个在读取时递增自身的计数器,在读取时应该自行 递增.我仍然访问一个资源的表示,虽然寿命非常短,我知道在阅读之后会立即更改.关于这一点,没有任何非ReSTful.
你在这里混合了几个问题.对REST接口的单个请求可以触发后端事务.但是,该事务必须在单个请求的范围内开始和结束.
REST接口不应该做的是让多个独立请求参与同一个后端"两阶段提交"事务.
第二个问题是GET请求是否可以进行更新.正如Jan在回答中指出的那样,在某些条件下允许GET产生副作用.他说它比我能说的要好得多,所以读了他的答案.
京公网安备 11010802040832号 | 京ICP备19059560号-6 