与 REST 和 Larman (RCP?) 系统操作作斗争

Question

在 Craig Larman 的书 Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition) 中，用例被转换为包含系统操作的系统序列图 (SSD)。这是一种首先进行高级设计的方法，可以很容易地追溯到需求（用例），然后通过 OO 设计原则在域级别详细说明系统操作来对其进行细化。

我正在尝试使用 RESTful 服务来理解这种方法。麻烦点似乎在于资源和无状态操作。

这是书中的一个示例，一个具有四个系统操作的 SSD：

SSD 也是表示层（左侧）和域层（右侧）的抽象。领域层可能还包括应用程序和/或业务逻辑。

在 Larman 的方法中，系统操作（例如，makeNewSale()）应由处理系统操作的 域 非表示层对象 GRASP Controller 处理。

现在，假设我们正在尝试以这种方式使用 RESTful 服务：

• REST 的统一接口约束是表示层的一部分。例如，可以配置对资源的 POST 操作所采用的 路由，使其最终调用域层中对象的某些操作。这个Byte Rot blog by Aliostad很好的解释了传统层架构和REST的细节。
  • 在 Larman 的示例中，收银员单击 GUI 中的某处以调用 http://...com/sales - POST request，最终 GRASP 控制器收到 makeNewSale()。 REST 部分http://...com/sales - POST request 为销售创建一个新资源，例如001 和makeNewSale() 被发送到一个GRASP 控制器对象。
• 会话控制器（在 GRASP 控制器模式中提到）在系统上不存在，因为 REST 操作在服务器上是无状态的。这意味着系统操作实际上可能需要更多参数来将状态信息传递给服务器，这在用例中并不明显。例如，makeNewSale() 可能需要接收和处理身份验证令牌作为参数，因为:System 没有会话信息。我在这里找到了一个相关的问题和答案RESTful Authentication

所以，假设我到目前为止的理解是正确的，我的问题是：

1. REST 的 统一接口 约束是否尊重表示层/域层分离的松散耦合？起初，它似乎是表示层的一个细节（就像 Java Swing 中的 actionPerformed() 方法）。但困扰我的部分是 http://...com/sales 直接绑定到 Sale（这是一个域）对象。
   
   另一种说法：通过创建 REST 资源和 REST 动词通过 Uniform 访问它们接口，应用程序/业务逻辑不是被放入表示层吗？ Larman 的 SSD 方法是关于层的，他明确指出应用程序逻辑不应进入表示层。例如，对http://...com/sales 的 POST 会创建一个新的sales/001 资源并发送makeNewSale()。第一部分似乎是业务逻辑。我的 REST 资源名称遵循我的许多域对象名称这一事实似乎我的表示层（更多）耦合到我的域层，而不是我使用 Swing 并且仅从 actionPerformed() 上的 @987654348 调用 makeNewSale() @。

2. Larman 的 SSD 概念面向 RCP 模型（在服务器中有状态），但 SSD 能否轻松地与 REST 理念相结合？例如，endSale() 的存在是为了使系统脱离enterItem() 调用的循环。在本书的后面，Larman 甚至为此提供了一个状态图：
   
   我读到了How to manage state in REST，如果需要，似乎必须注意在每个系统操作上传递状态（如上面的身份验证令牌示例），或者“状态”实际上封装在资源中。我想了想，使用 REST，endSale() 可能会被完全删除。

我在这里使用了一个具体的例子，所以答案也可以是具体的。

Answer 1

我会尝试解决您的问题，但请记住，这是一个非常值得商榷的话题..

1. REST 统一接口确实尊重表示和业务逻辑之间的关注点分离。分离是关于表示层不知道业务逻辑实现的细节，反之亦然，但是隐藏域实体可以做什么（即资源可用的服务）是没有意义的。您要隐藏的是如何执行操作。

2. REST 的 HATEOAS 原则规定资源的表示（域实体的实例）应封装客户端/服务器交互的状态，因此服务应以一种或另一种方式将该状态返回给客户端.这一点，以及超媒体的使用（即指向可用服务的链接 - 表示可以在给定状态的资源上执行的操作）应该很容易映射到您发布的状态图。

让我们继续你的例子：

假设有一个服务newSale 返回一个Sale 对象。必须使用POST 方法调用此服务。在Sale 的hypermedia 部分有2 个链接，一个指向addItem 服务（这也是POST 并接受Sale 对象的更新版本，保存后返回它)，还有一个到endSale 服务（也是POST），它保存Sale 并将其标记为“完成”。最后一个服务不返回任何资源表示，如果对象被成功保存，只返回 http 响应 OK。