Когда использовать @RestController vs @RepositoryRestResource

Ответ 1

Итак, короткая история в том, что вы хотите использовать @RepositoryRestResource так как это создает сервис HATEOAS с Spring JPA.

Как вы можете видеть здесь, добавляя эту аннотацию и связывая ее с вашим Pojo, вы получаете полнофункциональный сервис HATEOAS без необходимости реализовывать метод репозитория или методы сервиса REST.

Если вы добавите @RestController то вам придется реализовать каждый метод, который вы хотите представить самостоятельно, и он не будет экспортировать его в формат HATEOAS.

Ответ 2

Существует третий (и четвертый) вариант, который вы не указали, который должен использовать либо @BasePathAwareController, либо @RepositoryRestController, в зависимости от того, выполняете ли вы действия, специфичные для конкретной организации, или нет.

@RepositoryRestResource используется для установки параметров в общем интерфейсе репозитория - он автоматически создает конечные точки в зависимости от типа расширяемого репозитория (т.е. CrudRepository/PagingAndSortingRepository/etc).

@BasePathAwareController и @RepositoryRestController используются, когда вы хотите вручную создавать конечные точки, но хотите использовать конфигурации Spring Data REST, которые вы настроили.

Если вы используете @RestController, вы создадите параллельный набор конечных точек с различными параметрами конфигурации, то есть другим конвертером сообщений, различными обработчиками ошибок и т.д., но они будут счастливо сосуществовать (и, вероятно, вызвать путаницу).

Конкретную документацию можно найти здесь.

Ответ 3

Что ж, приведенные выше ответы верны в их контексте, но я приведу вам практический пример.

Во многих сценариях в рамках API нам необходимо предоставить конечные точки для поиска сущности на основе определенных критериев. Теперь, используя JPA, вам даже не нужно писать запросы, просто создайте интерфейс и методы с определенной номенклатурой Spring-JPA. Для предоставления таких API вы создадите уровень Service, который будет просто вызывать эти методы репозитория, и, наконец, Controllers, которые будут предоставлять конечные точки путем вызова уровня Service.

То, что здесь сделал Spring, позволяет вам выставлять эти конечные точки из таких интерфейсов (репозиториев), которые обычно являются вызовами GET для объекта поиска и в фоновом режиме генерируют необходимые файлы для создания конечных точек. Так что, если вы используете @RepositoryRestResource, нет необходимости создавать слой Service/Controller.

С другой стороны, @RestController - это контроллер, который специально работает с данными json, а остальные работают как контроллер. Короче говоря @Controller + @ResponseBody = @RestController.

Надеюсь это поможет.

Смотрите мой рабочий пример и блог для того же:
http://sv-technical.blogspot.com/2015/11/spring-boot-and-repositoryrestresource.html
https://github.com/svermaji/Spring-boot-with-hibernate-no-controller

Ответ 4

@RepositoryRestController переопределяет сгенерированные по умолчанию контроллеры Spring Data REST из открытого хранилища.

Чтобы воспользоваться преимуществами настроек Spring Data RESTs, конвертеров сообщений, обработки исключений и @RepositoryRestController другого, используйте аннотацию @RepositoryRestController вместо стандартной Spring MVC @Controller или @RestController

Например, эти контроллеры используют параметр spring.data.rest.basePath Spring Boot в качестве базового пути для маршрутизации.

См. Переопределение обработчиков ответов REST Spring Data.

Помните о добавлении @ResponseBody поскольку оно отсутствует в @RepositoryRestController

Если вы не @RepositoryRestResource(exported = false) репозиторий (помеченный как @RepositoryRestResource(exported = false)), используйте аннотацию @BasePathAwareController

Также будьте в курсе сумок

ControllerLinkBuilder не учитывает базовый путь Spring Data REST, и @RequestMapping не следует использовать на уровне класса/типа

а также

Базовый путь не отображается в HAL

Обходной путь для исправления ссылки: fooobar.com/info/2270546/...

ОБНОВЛЕНИЕ: наконец я предпочитаю не использовать @RepositoryRestController из-за большого количества обходных путей.