rest - 用于帐户传输示例的 REST 中的无状态与重载 POST

Question

我正在阅读 RESTful Web 服务 (OReilly)。作者提到无状态(应用程序状态而不是资源状态)是 ROA 的主要特征之一。

在本书的后面，当他以账户转账为例来解释交易时，他提到了将交易公开为资源的选项，这样比重载的 POST 更加 RESTful。

将事务公开为资源: 从书中总结:

将 50 美元从支票 (200 美元) 转至储蓄 (200 美元) 最终结果:支票(250 美元)和储蓄(150 美元)

支票账户资源在 /accounts/checking/11 公开，储蓄账户资源在 /accounts/savings/55 公开

POST /transactions/account-transfer HTTP/1.1
Host: example.com

返回

201 Created
Location: /transactions/account-transfer/11a5

投入 150 美元进行支票

PUT /transactions/account-transfer/11a5/accounts/checking/11 HTTP/1.1
Host example.com

balance=150

并节省 250 美元

PUT /transactions/account-transfer/11a5/accounts/savings/55 HTTP/1.1
Host: example.com

balance=250

最后设置commited=true

PUT /transactions/account-transfer/11a5/1.1
Host: example.com

committed=true

他说这可以通过构建与交易相关的操作队列来实现。摘自书中:

提交事务后，服务器可能会启动数据库事务，应用排队的操作，然后尝试提交数据库事务。

我的问题是:

维护服务器上的操作队列不是有状态的(应用程序状态)吗？因此就违反了无国籍性吗？

根据 Kai Mattern 的回答进行编辑

我认为你的意思是这个操作队列是资源状态而不是应用程序状态。书中也做了这样的区分，并说资源状态是好的，但不是应用程序状态。

但是，当您考虑无状态性时，您可以跨负载平衡服务器分发无状态应用程序，上面的一系列 POST 和 PUT 不会让您这样做。负载均衡器应将所有请求发送到 1 台特定服务器，因为该 1 台服务器上维护着一个操作队列。否则，如果上述资源被拆分驻留在多台计算机上(以实现负载平衡)，则可能需要类似 RESTful 两阶段提交事务的操作。

因此，对于这个特定示例，我们正在考虑 2 个选项:重载 POST 无状态应用程序与 2 阶段提交无状态应用程序。

是这样吗？

Answer 1

无状态并不意味着应用程序完全无能。它只是意味着应用程序不会通过 url、cookie 以及更重要的是数据库之外的其他方式来记住其状态。

这导致您不应将数据保存在服务器 session 之类的内容中，除非该 session 信息映射到 session 资源之类的内容。

因此，只要操作映射到资源，它就有机会成为无状态的。

请注意，将操作映射到 URL 通常会诱使您创建类似/transactions/startTransaction 之类的操作 - 这是错误的。将资源视为名词，而不是动词。

例如:

logging in -> create a session resource 
logging out -> delete the session resource

您的示例显示的正是这种行为:您创建一个资源(帐户转账)。您修改它以包含所有相关数据。然后你通过提交来改变它的状态(是的，状态)。

一旦写入提交标志，后端就会处理该事务。这可以通过将事务放入队列来完成。但这部分不是前端的一部分——无状态性可能会也可能不会就此止步。

因此，回答您的问题:不要将数据状态与应用程序状态混合在一起。将操作队列作为资源进行维护是无状态的。维护服务器内存中的操作(有状态应用程序服务器 session )则不然。