我们的应用程序结构如下：
用户界面＆lt; - ＆gt; REST API＆lt; - ＆gt;工作流程＆lt; - ＆gt;业务逻辑＆lt; - ＆gt; DAL＆lt; - ＆gt; DB
但是，我看到一些人们正在做的例子
用户界面＆lt; - ＆gt;工作流程＆lt; - ＆gt; REST API＆lt; - ＆gt;业务逻辑＆lt; - ＆gt; DAL＆lt; - ＆gt; DB
这是我的想象力吗？或者第二种选择是否可行？答案 0 :(得分：4)
这与你的工作流程有关。
作为应用程序状态引擎的超媒体将为您提供状态/资源的有向图。这些图形不必形成工作流程（例如具有特定的起点和终点）。它们很可能形成一个循环，具有双向链接等等。我假设这个图表以某种方式来自业务逻辑。
如果在UI中包含工作流程（通过图形从一个点到另一个点的特定路径），您可以对REST API进行一些假设，从而将UI与业务逻辑紧密耦合，从而将REST的可发现性排除在外
一般来说，混合工作流程（命令式编程）与REST（声明性编程）是非常有问题的。最好的方法是拥有一个自适应UI，允许用户导航状态网络，而不是通过定制的预定工作流程来约束它们。无论如何，这就是浏览器的工作方式。
如果您确实需要一些工作流，可以通过创建一系列互连资源并引导用户访问第一个来实现它们。从这个意义上说，你的第一个选择是有效的，虽然我发现业务逻辑和工作流的分离是一个灰色区域。工作流 是业务逻辑的一部分，或者为了更好地说明，来自业务逻辑。
这些意见是我自己的，但有关该主题的好的相关文章可以在这里找到：http://www.infoq.com/articles/webber-rest-workflow
答案 1 :(得分：1)
我刚刚接触到现在真正的ReST，希望我不会离开这里，但据我所知，客户应该负责选择转移到哪个状态（工作流程），所以我是认为＃2绝对有效。事实上，我很想知道如何在ReST API中实现工作流程。
答案 2 :(得分：-2)
REST是对资源的访问。问题是“什么是资源”？大多数答案是，这是一个非常低级别的信息。
复合应用程序或工作流程取决于一个或多个资源。
很难说资源依赖于工作流程。不可能。但很难。
在设计RESTful界面时，您只能获得CRUD规则。最常见的期望是回复完全符合您的要求。当您发布X时，您希望唯一的状态更改是创建新的X.不要创建带有可选Z对的X和Y.
我建议您的第二种方法是将REST置于更好的上下文中 - 访问有状态对象。