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

Question

我在SpringRest。参加了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数据什么时候是REST
• 对于一个实体，有可能将两种方法结合起来吗？事实证明，我是在浪费时间写一些简单的操作，比如创建、获取、保存、删除控制器，它可以移动到Spring Data REST
• 我能在RestConroller中实现我在Spring Data Rest中所做的一些操作吗？例如：
• 是否将实体属性值作为id而不是对象返回？我的意思是，我有实体本身的属性，对于这些字段，我有时需要返回它们的ID，而不是整个实体
• 有没有办法控制错误处理？在RestController中，我实现了ResponseEntityExceptionHandler扩展类，RestController中发生的所有错误都在一个地方以相同的方式处理，我始终知道所有错误都将返回大致相同的响应结构
• 数据验证必须取决于一个事实，即它过去是在从客户那里收到的DTO上进行验证的。在这方面有什么细微差别等着我吗

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

Answer 1

这是一个有趣的问题。

Spring Data Rest提供了抽象，并将大部分实现掌握在手中。这对于业务逻辑位于存储库层的小型应用程序很有帮助。对于具有简单直接业务逻辑的应用程序，我会选择此选项。

然而，如果我需要在您提到的每一层进行细粒度的控制（例如：事务、AOP、单元测试、复杂的业务决策等），这是大型应用程序最经常需要的，我更愿意编写每一层。

没有经验法则。

Answer 2

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

在生产中，我使用Spring Data REST作为数据库的包装器——在服务/微服务体系结构模型中，为了实现与数据库无关的应用程序，有时只需将核心数据库包装到这样的层中。然后服务将在这个包装器上应用业务逻辑，并为前端提供API。另一方面，如果您计划只使用这些生成的endpoint，Spring Data Rest（SDR）则不适合，因为您需要自定义将数据和数据操作提取到Repoitories/Services中的逻辑。您可以将两者结合起来，并对“简单”实体使用SDR，其中您只需要对它们进行基本的CRUD，对于复杂实体，您可以使用标准方法，将实体与内点解耦，并将自定义业务逻辑应用到服务中。混合使用这两种策略的缺点是，你的应用程序会不一致，一些“事情”会在开箱即用的情况下发生，这对这个项目的新开发人员来说是非常混乱的。

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

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

Answer 3

您有更多的控制权自行构建完整的堆栈，您使用DTO而不是返回实体对象，您可以组合服务中的存储库，您可以将业务逻辑放在服务层上。如果您没有做上述任何事情（您预计在不久的将来不会这样做），则无需再次编写所有样板文件，这就是Spring Data REST发挥作用的时候。