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

Question

我在Spring上执行REST API。在Spring Data Hibernate中学习了一门课程，发现它使REST API成为最耗时的方法。

当我向域中添加新实体时，我经历了以下对象链：

1. 实体-域对象
2. DTO-用于向/从客户端发送/接收对象
3. 映射器-在实体和DTO之间转换
4. 存储库-与数据库交互
5. RestController-用于处理API请求
6. 服务-对象的服务类

我的动作大致如下：

1. RestController处理请求-从客户端接收DTO（在创建新对象的情况下）
2. 控制器中的映射器将DTO转换为实体
3. 被称为服务
4. 服务访问存储库
5. 存储库返回执行结果（由实体创建）
6. 服务返回实体在RestController中创建
7. RestController向客户端返回类型为ResponseEntity的对象，在其中放置正文和响应代码。

您可以看到大量的动作和大量的对象。

但是后来我发现，如果您使用Spring Data REST，那么所有这些都不需要Spring提供的所有API。通常，您只需要创建一个实体和存储库。

事实证明，对于典型的CRUD类型的操作，我徒劳地编写了许多控制器及其方法。

问题：

• 我什么时候应该使用RestConroller，什么时候应该使用Spring Data REST？
• 是否可以将两个方法结合用于一个实体？原来，我在浪费时间在创建，获取，保存，删除控制器等简单操作上，可以将其移动到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），以及将复杂实体与标准方法配合使用，在标准方法中，将实体与Endopint分离并应用自定义业务逻辑进入服务。混淆这两种策略的不利之处在于您的应用程序将不一致，并且某些“事情”将立即发生，这对于该项目的新开发人员来说非常令人困惑。

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

简而言之，“标准”方式以开始编写重复性代码为代价提供了更大的灵活性。