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

Question

我最近一直在潜入ReST，但有些事情仍然让我感到困惑：

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

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

• 对于客户端，这意味着更新此资源的属性可能只会更改属性，或者也可能会执行许多其他操作。所以PUT = / = PUT，种类。
• 并且实施明智，我必须检查PUT请求改变的确切程度，并根据该触发器产生副作用。因此会有很多检查，例如if(old_attribute != new_attribute) {side_effects}

这应该是怎么回事？

BR， 菲利普

Answer 1

  

由于只有资源而且没有可以拨打的服务，我如何向客户提供仅执行操作并且不会更改任何数据的操作？

HTTP是文档传输应用程序。发送触发所需行为的文档（即：消息）。

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

Jim Webber非常清楚。

  

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

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

换句话说，你可以通过更具体的事情来解决PUT = / = PUT。

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

  

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

     

这应该是怎么回事？

排序。回顾Udi Dahan关于reliable messaging的演讲;它不是特定于REST的，但它可能有助于澄清责任分离。