您将 REST api 放在哪一层？答案

【问题标题】：In which layer are you putting your REST api?您将 REST api 放在哪一层？
【发布时间】：2010-09-15 12:12:11
【问题描述】：

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

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

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

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

这是我的想象吗？或者第二个选项被认为是一个可行的选择？

【问题讨论】：

【解决方案1】：

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

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

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

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

我建议您的第二种选择将 REST 置于更好的环境中——访问有状态对象。

【讨论】：

我认为我们必须同意在 REST 的这一方面存在分歧 :-) 我同意 Tim 的观点。 pluralsight.com/community/blogs/tewald/archive/2007/04/26/…
由于工作流依赖于资源并且资源由 REST 管理，我不确定您不同意哪个具体定义。

【解决方案2】：

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

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

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

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

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

这些观点是我自己的，但是关于这个主题的一篇很好的相关文章可以在这里找到：http://www.infoq.com/articles/webber-rest-workflow

【讨论】：

我同意业务逻辑和工作流的分离有点模糊。我需要做出区分，以确保读者不会认为我在推断第二种情况是直接暴露数据库。
我倾向于从 Microsoft Workflow Foundation 的角度来看待 Workflow 这个术语，它包括状态机和顺序工作流，因此在我看来 HATEOAS 很好地映射了工作流的概念。

【解决方案3】：

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

【讨论】：

是的，UI 选择通过工作流的路径，但 UI 可用的路径应由工作流引擎确定并通过 REST API 呈现。对我来说，只有当 UI 直接与 REST API 交互时，才能满足超媒体约束。
要直接回答您的问题，REST API 可以返回包含链接的表示。如果 UI 跟随链接，则表示希望从一种工作流状态转换到另一种。