Restful 业务逻辑 属性 更新
Restful business logic on property update
我正在构建一个 REST API 并且我试图尽可能地保持它 RESTful，但有些事情对我来说仍然不是很清楚。我看到很多关于类似问题的话题，但都过于关注更新数据的 "simple" 问题，我的问题更多是关于围绕它的业务逻辑。
我的主要问题是模型的部分更新触发的业务逻辑。我在网上看到很多关于 PATCH 方法、创建新的子资源或添加操作的不同意见，但使用保持 URI 简单和结构化的 REST 方法似乎往往适得其反。
我有一些记录需要处理（拒绝、验证、部分验证等），每个更改都会触发其他操作。
- 如果被拒绝，应发送一封包含原因的电子邮件
- 如果部分验证，则发送 link 来补充缺失的数据
- 如果验证通过，则必须创建一些其他资源。
可以对状态进行一些其他更改，但这对于示例来说已经足够了。
RESTful 方法是什么？
我的第一个想法是创建动作：
POST /record/:id/refusePOST /record/:id/validate ..等等
对我来说似乎RESTful但是太复杂了，而且，这种方法意味着有多个路由执行本质上相同的事情：更新记录对象中的一个字段
我也看到了像这样的 PATCH 方法的可能性：
PATCH /record/:id 其中我检查要更新的字段是否为状态，以及新值以了解要执行的操作。
但我觉得当我需要对记录的其他 属性 执行类似操作时，它会开始变得太复杂。
我的最后一个选择，我认为也许是最好的但我不确定它是否 RESTful，将是使用子资源状态并使用 PUT 来更新它：
PUT /record/:id/status，打开新值。
不管之前的值是多少，切换到accepted总是会触发创建，切换到refused总是会触发email ...等
这些方法是实现 RESTful 的方法吗？哪种方法更有意义？还有其他我没有想到的选择吗？
谢谢
What would be a RESTful way to do that ?
在 HTTP 中，您的 "uniform interface" 是文档存储。你的 Rest API 是一个外观，它接受具有远程创作语义的消息 (PUT/POST/PATCH)，并且你的实现产生有用的工作作为它处理这些消息的副作用。
参见 Jim Webber 2011。
I have some record that need to be proceeded ( refused, validated, partially validated ..etc ), each change trigger additional actions.
所以想想我们如何在网络上做到这一点。我们 GET 一些资源，返回的是 html 记录信息的表示和一堆描述我们可以执行的操作的表格。所以有一个被拒绝的表格，一个经过验证的表格，等等。用户在浏览器中选择要使用的正确表单，填写任何补充信息，然后提交表单。浏览器使用HTML表单处理规则，将表单信息转换为HTTP请求。
对于不安全的操作，表单被配置为使用 POST，因此浏览器知道表单数据应该是请求消息正文的一部分。
请求的 target-uri 就是用作表单操作的任何内容 -- 也就是说，表单的表示中包含描述表单应提交到何处的信息。
就浏览器和用户而言，target-uri 可以是任何东西。因此，您可以使用单独的资源来处理验证消息和拒绝消息等。
缓存是一个重要的想法，无论是在 REST 还是在 HTTP 中； HTTP 有特定的缓存失效规则。因此，通常情况下您会希望使用目标 uri 来标识您希望客户端在命令成功时重新加载的文档。
所以它可能是这样的：我们 GET /record/123，这给了我们一堆信息，还有一些描述我们如何更改记录的表格。所以填写一个，成功提交，现在我们希望表格消失 - 或者一组新的表格可用。因此，我们希望重新加载的是记录文档本身，表单的目标 uri 应该是 /record/123.
（因此 API 实现将负责查看 HTTP 请求，并弄清楚消息的含义。它们可能都转到单个 /record/:id POST处理程序，并且该代码会查看消息正文以找出应该由哪个内部函数完成工作）。
PUT/PATCH 是同一种想法，除了我们不提交表单，而是发送资源本身的编辑表示。我们 GET /record/123，更改状态（例如，拒绝），然后将我们新的记录表示形式的副本发送到服务器进行处理。因此，服务器有责任检查其资源表示与新提供的副本之间的差异，并根据它们计算任何必要的副作用。
My last option, and I think maybe the best but I'm not sure if it's RESTful, would be to use a sub-resource status and to use PUT to update it
没关系 - 想一想您所见过的任何网页，其中源包含 link 到图像，或 link 到 java 脚本。结果是两个资源而不是一个，每个资源都有单独的缓存条目——当您想要对资源缓存进行细粒度控制时，这很好。
但是有一个交易 - 您还需要获取更多资源。 （服务器推送缓解了部分问题）。
让服务器上的事情变得更容易可能会让客户端上的事情变得更难 - 您真的在尝试找到具有最佳平衡的设计。
我正在构建一个 REST API 并且我试图尽可能地保持它 RESTful，但有些事情对我来说仍然不是很清楚。我看到很多关于类似问题的话题，但都过于关注更新数据的 "simple" 问题，我的问题更多是关于围绕它的业务逻辑。
我的主要问题是模型的部分更新触发的业务逻辑。我在网上看到很多关于 PATCH 方法、创建新的子资源或添加操作的不同意见，但使用保持 URI 简单和结构化的 REST 方法似乎往往适得其反。
我有一些记录需要处理（拒绝、验证、部分验证等），每个更改都会触发其他操作。
- 如果被拒绝，应发送一封包含原因的电子邮件
- 如果部分验证，则发送 link 来补充缺失的数据
- 如果验证通过，则必须创建一些其他资源。
可以对状态进行一些其他更改，但这对于示例来说已经足够了。
RESTful 方法是什么？
我的第一个想法是创建动作：
POST /record/:id/refusePOST /record/:id/validate..等等
对我来说似乎RESTful但是太复杂了，而且，这种方法意味着有多个路由执行本质上相同的事情：更新记录对象中的一个字段
我也看到了像这样的 PATCH 方法的可能性：
PATCH /record/:id其中我检查要更新的字段是否为状态，以及新值以了解要执行的操作。
但我觉得当我需要对记录的其他 属性 执行类似操作时，它会开始变得太复杂。
我的最后一个选择，我认为也许是最好的但我不确定它是否 RESTful，将是使用子资源状态并使用 PUT 来更新它：
PUT /record/:id/status，打开新值。
不管之前的值是多少，切换到accepted总是会触发创建，切换到refused总是会触发email ...等
这些方法是实现 RESTful 的方法吗？哪种方法更有意义？还有其他我没有想到的选择吗？
谢谢
What would be a RESTful way to do that ?
在 HTTP 中，您的 "uniform interface" 是文档存储。你的 Rest API 是一个外观，它接受具有远程创作语义的消息 (PUT/POST/PATCH)，并且你的实现产生有用的工作作为它处理这些消息的副作用。
参见 Jim Webber 2011。
I have some record that need to be proceeded ( refused, validated, partially validated ..etc ), each change trigger additional actions.
所以想想我们如何在网络上做到这一点。我们 GET 一些资源，返回的是 html 记录信息的表示和一堆描述我们可以执行的操作的表格。所以有一个被拒绝的表格，一个经过验证的表格，等等。用户在浏览器中选择要使用的正确表单，填写任何补充信息，然后提交表单。浏览器使用HTML表单处理规则，将表单信息转换为HTTP请求。
对于不安全的操作，表单被配置为使用 POST，因此浏览器知道表单数据应该是请求消息正文的一部分。
请求的 target-uri 就是用作表单操作的任何内容 -- 也就是说，表单的表示中包含描述表单应提交到何处的信息。
就浏览器和用户而言，target-uri 可以是任何东西。因此，您可以使用单独的资源来处理验证消息和拒绝消息等。
缓存是一个重要的想法，无论是在 REST 还是在 HTTP 中； HTTP 有特定的缓存失效规则。因此，通常情况下您会希望使用目标 uri 来标识您希望客户端在命令成功时重新加载的文档。
所以它可能是这样的：我们 GET /record/123，这给了我们一堆信息，还有一些描述我们如何更改记录的表格。所以填写一个，成功提交，现在我们希望表格消失 - 或者一组新的表格可用。因此，我们希望重新加载的是记录文档本身，表单的目标 uri 应该是 /record/123.
（因此 API 实现将负责查看 HTTP 请求，并弄清楚消息的含义。它们可能都转到单个 /record/:id POST处理程序，并且该代码会查看消息正文以找出应该由哪个内部函数完成工作）。
PUT/PATCH 是同一种想法，除了我们不提交表单，而是发送资源本身的编辑表示。我们 GET /record/123，更改状态（例如，拒绝），然后将我们新的记录表示形式的副本发送到服务器进行处理。因此，服务器有责任检查其资源表示与新提供的副本之间的差异，并根据它们计算任何必要的副作用。
My last option, and I think maybe the best but I'm not sure if it's RESTful, would be to use a sub-resource status and to use PUT to update it
没关系 - 想一想您所见过的任何网页，其中源包含 link 到图像，或 link 到 java 脚本。结果是两个资源而不是一个，每个资源都有单独的缓存条目——当您想要对资源缓存进行细粒度控制时，这很好。
但是有一个交易 - 您还需要获取更多资源。 （服务器推送缓解了部分问题）。
让服务器上的事情变得更容易可能会让客户端上的事情变得更难 - 您真的在尝试找到具有最佳平衡的设计。