spring - 在 Spring 上实现 REST API 的两种方法

Question

我在 Spring 上做 REST API。学习了 Spring Data Hibernate 类(class)，发现它使 REST API 成为最耗时的方式。

当我向域添加新实体时，我浏览了以下对象链:

1. 实体 - 域对象
2. DTO - 用于向客户端传输对象或从客户端接收对象
3. Mapper - 在实体和 DTO 之间进行转换
4. 存储库 - 用于与数据库交互
5. RestController - 用于处理 API 请求
6. 服务 - 对象的服务类

我的行动大致如下:

1. RestController 处理请求 - 从客户端接收 DTO(在创建新对象的情况下)
2. Controller 中的映射器将 DTO 转换为实体
3. 服务被调用
4. 服务访问存储库
5. Repository返回执行结果(由Entity创建)
6. 服务返回实体是在 RestController 中创建的
7. RestController 返回给客户端一个 ResponseEntity 类型的对象，我在其中放置了正文和响应代码。

正如您所看到的一大串 Action 和大量对象。

但后来我发现，如果你使用 Spring Data REST，这一切并不需要 Spring 提供的所有 API。一般来说，您只需要创建一个Entity和Repository即可。

事实证明，对于典型的CRUD类型的操作，我白白写了很多 Controller 及其方法。

问题:

• 什么时候应该使用 RestConroller，什么时候应该使用 Spring Data REST？
• 是否可以将两种方法组合用于一个实体？事实证明，我在浪费时间编写简单的操作，例如创建、获取、保存、删除 Controller ，它可以转移到 Spring Data REST。
• 我能够在 RestConroller 中实现我在 Spring Data Rest 中执行的一些操作吗？如:
• 返回实体属性值作为 id 而不是对象？我的意思是，我的实体属性本身就是实体，对于这些字段，我有时需要返回它们的 ID，而不是整个实体。
• 有什么方法可以控制错误处理吗？在 RestController 中，我实现了 ResponseEntityExceptionHandler 扩展类，并且在 RestController 中发生的所有错误都以相同的方式在一个地方进行处理，并且我始终知道所有错误都会返回大致相同的响应结构。
• 数据验证必须取决于这样一个事实:数据过去是在从客户端收到的 DTO 上进行验证的。在这方面有什么细微差别等待着我吗？

我对如何前进有点困惑。请给我你对此的建议和想法。推进使用什么以及如何使用。

Answer 1

Spring Data REST 可以为您做的是将普通存储库搭建为休息服务的脚手架。它要快得多，理论上它应该很灵活，但在实践中很难实现比对存储库的 REST 访问更多的东西。

在生产中，我使用 Spring Data REST 作为数据库的包装器 - 在服务/微服务架构模型中，有时您只需将核心数据库包装到此类层中，以实现与数据库无关的应用程序。然后，服务将在此包装器之上应用业务逻辑，并为前端提供 API。另一方面，如果您打算仅使用这些生成的端点，则 Spring Data Rest(SDR) 不适合，因为您需要自定义用于获取数据和数据操作到存储库/服务的逻辑。您可以将两者结合起来，并将 SDR 用于“简单”实体，您只需要对它们进行基本的 CRUD，而对于复杂实体则采用标准方法，您可以将实体与端点分离并应用自定义业务逻辑进入服务。混合这两种策略的缺点是您的应用程序将不一致，并且一些“事情”会开箱即用，这对于该项目的新开发人员来说非常令人困惑。

自己编写这些类看起来浪费时间和精力，但这只是因为您的应用程序还没有复杂的数据库和/或业务逻辑。

简而言之 - “标准”方式提供了更大的灵活性，但代价是在一开始就编写重复的代码。