2

我正在阅读 RESTful Web 服务 (OReilly)。作者提到无状态（Application state 与 Resource state 相反）是 ROA 的主要特征之一。

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

将交易公开为资源：从书中总结：

将 50 美元从 Checking ($200) 转移到 Savings ($200) 最终结果：Checking ($250) 和 Savings ($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

最后把committed=true

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

committed=true

他说，这可以通过建立与交易相关的动作队列来实现。从书中：

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

我的问题是：

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

在 Kai Mattern 的回答之后进行编辑

我认为您所说的是这个动作队列是资源状态而不是应用程序状态。这本书也做出了这种区分，并说资源状态是好的，但不是应用程序状态。

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

因此，对于这个特定的示例，我们正在查看 2 个选项 Overloaded POST Stateless App Vs 2 phase commit Stateless App。

是这样吗？

4

1 回答 1

2

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

这导致您不应将数据保存在诸如服务器会话之类的东西中，除非该会话信息被映射到诸如会话资源之类的东西中。

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

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

例如：

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

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

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

因此，回答您的问题：不要将数据状态与应用程序状态混合。将动作队列作为资源维护是无状态的。在服务器内存中维护操作（有状态的应用程序服务器会话）不是。

于 2012-08-29T17:00:50.990 回答