关于属性更新的繁琐业务逻辑

Question

我正在构建REST API，并且试图将其保持为RESTful，但是对于我来说，有些事情仍然不太清楚。我看到了很多有关类似问题的话题，但都集中在更新数据的“简单”问题上，我的问题更多地是围绕着该问题的业务逻辑。

我的主要问题是由模型的部分更新触发的业务逻辑。我在网上看到许多关于PATCH方法，创建新的子资源或添加操作的不同意见，但与保持URI简单和结构化的REST方法通常似乎适得其反。]

我有一些记录需要处理（拒绝，验证，部分验证..etc等，每个更改都会触发其他操作。

• 如果被拒绝，则应发送带有原因的电子邮件
• 如果已部分验证，则发送用于填写缺失数据的链接
• 如果已验证，则必须创建其他资源。

可以对状态进行其他一些更改，但这对于示例来说就足够了。

什么是RESTful方式？

我的第一个想法是创建动作：

• POST /record/:id/refuse
• POST /record/:id/validate ..etc

对我来说似乎是RESTful的，但是太复杂了，而且，这种方法意味着让多个路由执行本质上相同的事情：更新记录对象中的一个字段

我也看到了类似PATCH方法的可能性：

• PATCH /record/:id，我在其中检查要更新的字段是否为状态，并检查要执行哪个操作的新值。

但是当我需要对记录的其他属性执行类似的操作时，它可能会变得太复杂。

我的最后一个选择，也许是最好的选择，但我不确定它是否是RESTful，将使用子资源状态并使用PUT更新它：

• PUT /record/:id/status，并打开新值。

无论以前的值是什么，切换到已接受将始终触发创建，切换到拒绝将始终触发电子邮件...等

实现那RESTful的那些方法，哪一种更有意义？还有其他我没想到的选择吗？

谢谢

我正在构建REST API，并且试图将其保持为RESTful，但是对于我来说，有些事情仍然不太清楚。我看到了很多类似问题的话题，但都集中在“ ...

Answer 1

什么是RESTful方式？