language-agnostic - 您将 REST api 放在哪一层？

Question

我们的应用程序的结构类似于：

UI <--> REST API <--> 工作流 <--> 业务逻辑 <--> DAL <--> DB

但是，我看到一些看起来人们正在做的例子

UI <--> 工作流 <--> REST API <--> 业务逻辑 <--> DAL <--> DB

这是我的想象吗？或者第二种选择是否被认为是可行的选择？

Answer 1

这确实与您所说的工作流程有关。

作为应用程序状态引擎的超媒体将为您提供状态/资源的有向图。这些图不必形成工作流（例如，具有特定的起点和终点）。它们很可能形成一个循环，具有双向链接等等。我假设这个图是从业务逻辑中衍生出来的。

如果你在你的 UI 中包含你的工作流（通过图表从一个点到另一个点的特定路径），你会对 REST API 做出一些假设，因此将你的 UI 与业务逻辑紧密耦合，从而抛弃了 REST 的可发现性。

一般来说，将工作流（命令式编程）与 REST（声明式编程）混合是非常有问题的。最好的方法是拥有一个自适应 UI，它可以允许用户导航状态网络，而不是通过定制的、预定的工作流程来限制它们。无论如何，这就是浏览器的工作方式。

但是，如果您确实需要一些工作流程，您可以通过创建一个相互关联的资源链并将用户引导到第一个资源来实现它们。从这个意义上说，您的第一个选项将是有效的，尽管我发现业务逻辑和工作流的分离是一个灰色区域。工作流是业务逻辑的一部分，或者说得更好，是从业务逻辑派生的。

这些意见是我自己的，但是可以在此处找到有关该主题的良好相关文章：http: //www.infoq.com/articles/webber-rest-workflow

Answer 2

我现在才刚刚接触到 ReST 的真正含义，希望我不会在这里偏离基础，但据我所知，客户应该负责选择要转移到的状态（工作流程），所以是的，我认为 #2绝对有效。事实上，我很想知道你是如何在你的 ReST API 中实现工作流的。

Answer 3

REST 是对资源的访问。问题是“什么是资源”？大多数答案是它是一条非常低级的信息。

复合应用程序或工作流依赖于一个或多个资源。

很难说资源依赖于工作流。并非不可能。但是很难。

在设计 RESTful 界面时，您只有可用的 CRUD 规则。最常见的期望是响应完全符合您的要求。当您发布一个 X 时，您期望唯一的状态变化是创建一个新的 X。而不是创建一个带有可选 Z 对的 X 和 Y。

I'd suggest that your second alternative puts REST in a better context -- access to stateful objects.