我正在开发一个 RESTful API。这是我的第一个 API，也是我的第一个真正大型的编码项目。因此，我仍在学习很多关于架构等方面的知识。
目前，我的 api 设置在以下几层:
- HTTP 层
- 资源层
- 域模型/业务逻辑层
- 数据访问/存储库层
- 持久存储/数据库层
我目前遇到的问题是我需要将工作流对象/管理器放在哪里？我所说的工作流程是指评估最终用户下一步需要什么的代码。例如，电子商务工作流程。用户将商品添加到购物篮，然后结帐，然后填写个人详细信息，然后付款。工作流程将负责决定接下来要执行哪些步骤，以及不允许执行哪些步骤。例如，用户在输入个人详细信息之前尝试付款不会导致 API 中出现错误(也许他们回想起付款的 URI 并尝试跳过某个步骤)。工作流程将检查之前的所有步骤是否已完成，如果没有完成，则不允许付款。
目前，我的工作流程逻辑位于资源层。我正在使用超媒体链接向用户展示工作流程，例如提供“下一步”链接。我遇到的问题是资源层是顶层，并且与表示更加一致。我觉得它需要对底层域模型了解太多才能有效地评估工作流程，即它需要知道在允许付款之前必须检查 personal_detail 实体。
这现在让我认为工作流属于域模型。这确实更有意义，因为工作流实际上是业务逻辑的一部分，因此我认为最好放置在域层中。毕竟，用其他东西替换资源层，您仍然需要底层工作流程。
但现在的问题是工作流需要了解多个领域对象才能完成其逻辑。现在感觉它可能在自己的层中是正确的吗？在资源层和域层之间？
- HTTP 层
- 资源层
- 工作流程层
- 域模型/业务逻辑层
- 数据访问/存储库层
- 持久存储/数据库层
我只是想知道是否有人对此有其他看法或想法？正如我所说，我过去没有应用程序经验，不知道工作流程应该放在哪里。我真的只是第一次学习这个，所以想确保我以正确的方式进行。
包含此内容的文章或博客的链接将不胜感激。喜欢阅读不同的实现。
编辑
为了澄清，我声明 HATEOAS 允许客户端浏览“工作流程”，但我的 API 中必须有某些内容知道要显示哪些链接，即它确实定义了允许的工作流程。它在资源中显示与工作流相关的链接，但此外它还验证请求是否与工作流同步。虽然我同意客户端可能只会遵循资源中提供的链接，但休息的危险(和美丽)在于其 URI 驱动，因此没有什么可以阻止顽皮的客户端尝试通过以下方式“跳过”工作流程中的步骤:对 URI 进行有根据的猜测。 API 需要发现这一点并返回 302 响应。
最佳答案
这个问题的答案让我进行了相当多的研究，但基本上“工作流”部分与 REST 完全无关，更多地与应用程序层有关。
我的系统的应用程序逻辑和 REST API 耦合得太紧密。我通过重构来减少耦合解决了我的问题，现在工作流程位于应用程序的上下文中
关于api - REST API : Where should I code my workflow?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23114421/