何时使用@RestController vs @RepositoryRestResource

我一直在研究如何在REST中使用Spring的各种示例。我们的最终目标是Spring HATEOAS / HAL设置

我已经看到了在Spring中呈现REST的两种不同的方法

我正在努力寻找的东西是为什么你会用另一个。当试图实施最好的HAL？

我们的数据库后端是Neo4j。

那么简短的故事就是你想要使用@RepositoryRestResource，因为这会使用Spring JPA创build一个HATEOAS服务。正如你在这里看到的，添加这个注解并将其链接到Pojo，你就可以拥有一个完整的HATEOAS服务，而不必实现存储库方法或者REST服务方法

如果你添加@RestController，那么你必须实现你想要公开的每个方法，也不会将它导出为HATEOAS格式

还有第三个（和第四个）选项，你没有概述，根据是否执行特定于实体的动作，使用@BasePathAwareController或@RepositoryRestController。

@RepositoryRestResource用于设置公共Repository接口上的选项 – 它将根据正在扩展的Repository的types（即CrudRepository / PagingAndSortingRepository / etc）根据需要自动创build端点。

@BasePathAwareController和@RepositoryRestController用于手动创build端点，但要使用已设置的Spring Data RESTconfiguration。

如果你使用@RestController，你将创build一组具有不同configuration选项的并行端点 – 即不同的消息转换器，不同的error handling程序等 – 但它们将高兴地共存（并可能导致混淆）。

具体的文档可以在这里find。

那么，上面的答案在他们的语境中是正确的，我仍然给你实际的例子。

在许多情况下，作为API的一部分，我们需要提供基于特定条件的实体search端点。现在使用JPA，您甚至不必编写查询，只需使用特定的Spring-JPA术语创build一个接口和方法即可。为了公开这样的API，你将使服务层简单地调用这些库方法，最后通过调用服务层来暴露端点的控制器。

Spring在这里做了什么，允许你从这样的接口（仓库）公开这些端点，这些接口通常是GETsearch实体的调用，并在后台生成必要的文件来创build最终的端点。所以，如果您使用的是@RepositoryRestResource，则不需要制作服务/控制器层。

另一方面@RestController是一个控制器，专门处理json数据和作为控制器rest工作。总之@Controller + @ResponseBody = @RestController。

希望这可以帮助。