http - 了解 REST : is GET fundamentally incompatible with any "number of views" counter?

Question

我正在尝试理解 REST。在 REST 下，GET 不得在服务器上触发事务(这是每个人都同意的定义，它是 REST 的基础)。

假设您有一个网站像 stackoverflow.com(我说像 所以如果我弄错了 SO 的基本细节，它不会改变任何东西我的问题)，每当有人使用 GET 阅读问题时，也会有一些显示显示“这个问题已被阅读 256 次”。

现在有人读了那个问题。计数器现在是 257。GET 是事务性的，因为 View 的数量增加了，现在又增加了。数据库中的“查看次数”增加了，对此没有争论(例如在 SO 上，总是显示任何问题被查看的次数)。

那么，REST GET 是否与网站中任何类“查看次数”的功能从根本上不兼容？

那么它应该是“RESTFUL”吗，SO 主页是否应该停止显示使用 GET 访问的纯 HTML 链接或停止显示“此问题已被查看 x 次”？

因为在数据库中递增计数器是事务性的，因此是“不稳定的”？

编辑只是为了让谷歌搜索这个的人可以获得一些指示:

来自 http://www.xfront.com/REST-Web-Services.html :

4。通过 HTTP GET 访问的所有资源都应该没有副作用。也就是说，请求应该只返回资源的表示。调用资源不应导致修改资源。

现在对我来说，如果表示包含“ View 数”，它就是资源的一部分 [并且在 SO 中，问题所具有的“ View 数”是一个非常重要的信息]，并且访问它肯定会修改资源。

这与真正的 RESTFUL HTTP GET 形成鲜明对比，比如您可以在 Amazon S3 资源上创建的 GET，保证您的 GET 不会修改您返回的资源。

但后来我还是很困惑。

Answer 1

重要的是，从客户端的角度来看，GET 根据定义是安全的(没有副作用)，因此客户端可以安全地调用 GET 任意次数，而无需考虑可能产生的任何副作用。

服务器做什么是服务器的责任。在 View 计数器的情况下，如果服务器认为计数器的更新是副作用，则服务器必须做出决定。通常不会，因为计数器首先是资源语义的一部分。

但是，服务器可能决定不为某些请求增加计数器，例如爬虫的 GET。

一月