RESTful API：我应该在哪里编码我的工作流？

我正在开发一个RESTful API。这是我的第一个API，也是我的第一个真正的大型编码项目。因此，我仍然在学习很多关于建筑的知识

目前，我在以下层中设置了api：

• HTTP层
• 资源层
• 域模型/业务逻辑层
• 数据访问/存储库层
• 持久存储/数据库层

我目前遇到的问题是，我需要将工作流对象/管理器放在哪里？所谓工作流，我指的是评估最终用户下一步所需的代码。例如，电子商务工作流。用户将项目添加到购物篮中，然后结账，然后填写个人详细信息，然后付款。工作流将负责决定下一步是什么步骤，以及哪些步骤是不允许的。例如，用户在输入个人详细信息之前尝试付款不会导致API中出现错误（可能他们调用付款的URI并尝试跳过一步）。工作流将检查之前的所有步骤是否已完成，如果未完成，将不允许付款

目前，我的工作流逻辑位于资源层。我使用超媒体链接向用户展示工作流，例如提供“下一步”链接。我遇到的问题是，资源层是一个顶级层，更符合表示。我觉得它需要了解太多关于底层域模型的信息才能有效地评估工作流，也就是说，它需要知道它必须在允许付款之前检查

personal\u detail

s实体

这让我想到工作流属于域模型。这确实更有意义，因为工作流实际上是业务逻辑的一部分，因此我认为最好放在域层。毕竟，用其他东西替换资源层，您仍然需要底层工作流

但现在的问题是，工作流需要多个域对象的知识才能完成其逻辑。它现在感觉是正确的，它可能进入它自己的层？在资源层和域层之间

• HTTP层
• 资源层
• 工作流层
• 域模型/业务逻辑层
• 数据访问/存储库层
• 持久存储/数据库层

我只是想知道是否有人对此有其他的看法或想法？正如我所说，我没有过去的应用程序经验来知道工作流应该放在哪里。我真的只是第一次了解这一点，所以我想确保我的方法是正确的

链接到文章或博客，包括这将不胜感激。喜欢阅读不同的实现

编辑

---

为了澄清，我发布了HATEOAS，它允许客户端在“工作流”中导航，但我的API中必须有某种东西知道要显示哪些链接，即它确实定义了允许的工作流。它在资源中显示与工作流相关的链接，但还验证请求是否与工作流同步。虽然我同意客户机可能只会遵循资源中提供的链接，但rest的危险（和美丽）在于其URI是受驱动的，因此没有什么可以阻止淘气的客户机通过对URI进行有根据的猜测来“跳过”工作流中的步骤。API需要发现这一点并返回302响应。

REST鼓励您根据一组已建立的动词（GET、POST、PUT、DELETE）创建一个名词词汇表（用户、产品、购物车）。如果您坚持这一规则，那么在您的示例中，工作流实际上是由用户与您的站点的交互集定义的。这是用户如何使用你的应用程序，这实际上是由用户界面定义的。您的REST服务应该对无效状态请求做出适当的反应，例如尝试使用空购物车结账，但UI也可能使用脚本阻止此类请求，这是REST的可选特性

例如，向用户显示产品的UI可能还会显示一个链接，允许用户将该产品添加到购物车（POST-shoppingcart/{productId}）。服务器实际上不应该关心用户是如何到达该帖子的，只应该将该产品添加到用户的购物车中，并将购物车的更新表示返回给用户。然后，UI可以使用javascript确定是否仅当购物车有一个或多个项目时才显示指向签出的链接

---

因此，您的工作流似乎不在REST服务中，而是由页面中的导航定义的，该导航在用户请求时与REST服务交互。当然，您可能有内部工作流，这些工作流必须根据用户设置的状态发生在应用程序中。但您似乎描述的是站点内的用户交互，虽然这确实是一个工作流，但它似乎由您的用户界面来定义，而不是由专用的服务器端组件/层来定义。

这个问题的答案花了我相当多的研究，但基本上，“工作流”部分与REST无关，更多的是与应用程序层有关

---

我的系统将应用程序逻辑和RESTAPI紧密耦合。我通过重构来减少耦合，从而解决了我的问题，现在工作流位于应用程序的上下文中

您可能希望按照DDD（域驱动设计）的思路重新确定架构的方向，并可能使用MSA，通过这种方式，您可以从编排的工作流转换为EDA和微流程编排。

您将触及API的工作流（也称为业务逻辑）部分。从技术上讲，这与作为接口的API部分无关。当然，正如您所提到的，HATEOAS允许您建议某些有效的操作，但您应该小心维护

休息应用