您将把您的RESTAPI放在哪个层?

它确实与您所说的工作流程相关。

作为应用程序状态引擎的超媒体将为您提供状态/资源的有向图。这些图不必构成工作流(例如具有特定的起点和终点)。它们很可能形成一个循环,有双向链接等等。我假设这个图从某种程度上脱离了业务逻辑。

如果您在UI中包含您的工作流(通过图表从一个点到另一个点的特定路径),那么您将对RESTAPI进行一些假设,从而使您的UI与业务逻辑紧密耦合,从而放弃了REST的可发现性。

通常,将工作流(强制编程)与REST(声明性编程)混合是非常有问题的。最好的方法是拥有一个自适应的用户界面,允许用户浏览状态网络,而不是通过定制的、预先确定的工作流来约束它们。无论如何,这就是浏览器的工作原理。

如果您真的需要一些工作流,那么您可以通过创建一个相互连接的资源链并指导用户使用第一个资源来实现它们。从这个意义上讲,您的第一个选项是有效的,尽管我发现业务逻辑和工作流的分离是一个灰色区域。工作流 是 业务逻辑的一部分,或者更准确地说,是被驱动的 从 业务逻辑。

这些意见都是我自己的,但是关于这一主题的一篇好的相关文章可以在这里找到: http://www.infoq.com/articles/webber-rest-workflow

我刚刚接触到了REST的真正含义,希望我不会偏离基础,但据我所知,客户机应该负责选择要传输到的状态(工作流),所以是的,我认为2是绝对有效的。实际上,我想知道您如何在RESTAPI中实现工作流。

休息是获取资源。问题是“什么是资源”?大多数答案是,这是一个相当低级的信息。

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

很难说资源依赖于工作流。不允许。但很难。

当设计一个RESTful接口时,您只有CRUD规则可用。最常见的期望是响应完全符合您的请求。当您发布一个x时,您希望唯一的状态更改是创建一个新的x。而不是使用可选的z对创建一个x和y。

我建议您的第二种选择将REST放在一个更好的上下文中——对有状态对象的访问。