RESTful API:我应该在哪里编码我的工作流程? [英] RESTful API: Where should I code my workflow?

问题描述

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

I am developing a RESTful API. This is my first API, but also my first really big coding project. As such, I'm still learning a lot about architecture etc.

目前，我的 api 设置分为以下几层:

Currently, I have my api setup in the following layers:

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

我目前遇到的问题是我需要将工作流对象/管理器放在哪里?通过工作流，我的意思是评估最终用户需要什么下一步的代码.例如，电子商务工作流.用户将商品添加到购物篮，然后结帐，然后填写个人详细信息，然后付款.工作流将负责决定下一步是什么，但也决定哪些步骤是不允许的.例如，用户不能在输入个人详细信息之前尝试付款，从而导致 API 中的错误(也许他们会回忆付款的 URI 并尝试跳过某个步骤).工作流将检查是否已完成所有前面的步骤，如果未完成，则不允许付款.

The issue I have run into at the moment is where do I need to put workflow objects / managers? By workflows, I mean code that evaluates what next step is required by the end user. For example, an e-commerce workflow. User adds item to basket, then checks out, then fills in personal details, then pays. The workflow would be responsible for deciding what steps are next, but also what steps are NOT allowed. For example, a user couldn't cause errors in the API by trying to pay before they have entered personal details (maybe they recall the URI for payments and try to skip a step). The workflow would check to see that all previous steps had been completed, if not, would not allow payment.

目前，我的工作流逻辑在资源层.我正在使用超媒体链接向用户展示工作流程，例如提供下一步"链接.我遇到的问题是资源层是顶级层，更符合表示.我觉得它需要对底层域模型了解太多才能有效评估工作流，即它需要知道在允许付款之前必须检查 personal_detail 的实体.

Currently, my workflow logic is in the Resource Layer. I am using hypermedia links to present the workflow to the user e.g. providing a 'next step' link. The problem I have with this is that the resource layer is a top level layer, and more aligned with presentation. I feel it needs to know too much about the underlying domain model to effectively evaluate a workflow i.e. it would need to know it has to check the personal_details entity before allowing payment.

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

This now leads me to thinking that workflows belong in the domain model. This does make a lot more sense, as really workflows are part of the business logic and I think are therefore best placed in the domain layer. After all, replace the Resource Layer with something else, and you would still need the underlying workflows.

但现在的问题是工作流需要了解多个域对象才能完成其逻辑.现在感觉它可能在它自己的层中是正确的?资源层和领域层之间?

But now the problem is that workflows required knowledge of several domain objects to complete their logic. It now feels right that it maybe goes in its own layer? Between Resource and Domain Layer?

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

我只是想知道是否有人对此有其他看法或想法?正如我所说，我没有过去的应用程序经验，不知道应该将工作流放在哪里.我真的只是第一次学习这个，所以想确保我以正确的方式去做.

Im just wondering if anyone had any other views or thoughts around this? As I said, I have no past application experience to know where workflows should be placed. Im really just learning this for the first time so want to make sure I'm going about it the right way.

如果能提供涵盖此内容的文章或博客的链接，我们将不胜感激.喜欢阅读不同的实现.

Links to articles or blogs that cover this would be greatly appreciated. Love reading up on different implementations.

编辑

为了澄清，我发布 HATEOAS 允许客户端浏览工作流程"，但我的 API 中必须有一些东西知道要显示哪些链接，即它确实定义了允许的工作流程.它在资源中显示与工作流相关的链接，但另外它还验证请求与工作流同步.虽然我同意客户可能只会遵循资源中提供的链接，但休息的危险(和美丽)在于它的 URI 驱动，所以没有什么能阻止淘气的客户试图跳过"工作流程中的步骤对 URI 进行有根据的猜测.API 需要发现这一点并返回 302 响应.

To clarify, I release that HATEOAS allows the client to navigate through the 'workflow', but there must be something in my API that knows what links to show i.e. it is really defining the workflow that is allowed. It presents workflow related links in the resource, but additionally it validates requests are in sync with the workflow. Whilst I agree that a client will probably only follow the links provided in the resource, the danger (and beauty) of rest, is that its URI driven, so there is nothing stopping a mischievous client trying to 'skip' steps in the workflow by making an educated guess at the URI. The API needs to spot this and return a 302 response.

推荐答案

这个问题的答案让我做了一些研究，但基本上工作流程"部分与 REST 完全没有关系，还有更多事情要做与应用层.

The answer to this question has taken me a fair bit of research, but basically the 'workflow' part has nothing to do with REST at all and more to do with the application layer.

我的系统的应用程序逻辑和 REST API 耦合得太紧.我通过重构来减少耦合解决了我的问题，现在工作流存在于应用程序的上下文中

My system was had the application logic and REST API too tightly coupled. I solved my problem by refactoring to reduce the coupling and now the workflow lives within the context of the application

这篇关于RESTful API:我应该在哪里编码我的工作流程?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！