ReST 理念——如何处理服务和副作用

Question

我最近一直在研究 ReST，但仍有一些问题困扰着我：

1) 由于只有资源，没有服务可以调用，我如何向客户端提供只做东西而不更改任何数据的操作？ 例如，在我的应用程序中，可以触发连接到远程服务器并执行 shell 脚本的服务。我不知道这种情况如何应用于资源？

2) 我不确定的另一件事是副作用：假设我有一个可以处于某些状态的资源。当转换到另一种状态时，可能会发生很多事情（可能会发送电子邮件）。转换由客户端触发。我是否应该仅通过让资源通过 PUT 更新来处理此转换？这感觉有点奇怪。

• 对于客户端，这意味着更新此资源的属性可能只会更改属性，或者还可能做很多其他事情。所以 PUT =/= PUT，有点。
• 在实施方面，我必须检查 PUT 请求的确切更改，并据此触发副作用。所以会有很多检查，比如if(old_attribute != new_attribute) {side_effects}

这是应该的吗？

BR, 菲利普

Answer 1

既然只有资源，没有服务可以调用，那我怎么给客户端提供只做东西不改变任何数据的操作呢？

HTTP 是一个文档传输应用程序。发送触发您想要的行为的文档（即：消息）。

换句话说，您可以将发送的消息视为对任务的描述，或者将其视为添加到任务队列中的条目。 “我正在创建一个任务资源来描述我想要完成的一些工作。”

Jim Webber 很好地涵盖了这一点。

我不确定的另一件事是副作用：假设我有一个可以处于某些状态的资源。当转换到另一种状态时，可能会发生很多事情（可能会发送电子邮件）。转换由客户端触发。我是否应该仅仅通过让资源通过 PUT 更新来处理这种转换？

也许可以，但这不是您唯一的选择——您可以通过让客户端放置一些其他资源（即描述要进行的更改的消息）来处理转换。这提供了许多消息（命令），这些消息（命令）描述了对域实体的非常具体的修改。

换句话说，您可以通过放置更具体的内容来解决 PUT =/= PUT。

（在 HTTP 中，PUT 的语义是有效地创建或替换。这对于愚蠢的文档或 CRUD 来说非常有用，但在应用于拥有自己代理的实体时需要一些设计帮助。）

在实现方面，我必须检查 PUT 请求的确切变化，并据此触发副作用。

这是应该的吗？

有点。回顾 Udi Dahan 在reliable messaging 上的演讲；它不是特定于 REST 的，但它可能有助于澄清这里的职责分离。