Перейти к основному содержимому

Настройка конечных точек HTTP в Spring Data REST

· 4 мин. чтения

1. Введение

Spring Data REST может удалить множество шаблонов, которые являются естественными для служб REST.

В этом руководстве мы рассмотрим, как настроить некоторые значения HTTP-привязки Spring Data REST по умолчанию .

2. Основы репозитория Spring Data REST

Для начала создадим пустой интерфейс, расширяющий интерфейс CrudRepository , указав тип нашей сущности и тип ее первичного ключа:

public interface UserRepository extends CrudRepository<WebsiteUser, Long> {}

По умолчанию Spring генерирует все необходимые сопоставления , настраивает каждый ресурс так, чтобы он был доступен через соответствующие методы HTTP, и возвращает правильные коды состояния.

Если нам не нужны все ресурсы, определенные в CrudRepository , мы можем расширить базовый интерфейс репозитория и определить только те ресурсы, которые нам нужны :

public interface UserRepository extends Repository<WebsiteUser, Long> {
void deleteById(Long aLong);
}

При получении запроса Spring считывает используемый HTTP-метод и, в зависимости от типа ресурса, вызывает соответствующий метод, определенный в нашем интерфейсе , если он присутствует, или возвращает HTTP-статус 405 (метод не разрешен) в противном случае.

Что касается приведенного выше кода, когда Spring получает запрос DELETE, он выполняет наш метод deleteById .

3. Ограничение доступа к методам HTTP

Давайте представим, что у нас есть система управления пользователями. Тогда у нас может быть UserRepository.

И, поскольку мы используем Spring Data REST, мы многое получаем от расширения CrudRepository :

@RepositoryRestResource(collectionResourceRel = "users", path = "users")
public interface UserRepository extends CrudRepository<WebsiteUser, Long> {}

Все наши ресурсы предоставляются с использованием шаблона CRUD по умолчанию , поэтому выполните следующую команду:

curl -v -X DELETE http://localhost:8080/users/<existing_user_id>

вернет HTTP-статус 204 (контент не возвращен) для подтверждения удаления.

Теперь предположим, что мы хотим скрыть метод удаления от третьих лиц, но при этом иметь возможность использовать его внутри.

Затем мы можем сначала добавить сигнатуру метода deleteById в наш интерфейс, которая сигнализирует Spring Data REST о том, что мы собираемся ее настроить.

Затем мы можем использовать аннотацию @RestResource(exported = false) , которая настроит Spring для пропуска этого метода при запуске показа метода HTTP :

@Override
@RestResource(exported = false)
void deleteById(Long aLong);

Теперь, если мы повторим ту же команду cUrl , показанную выше, вместо этого мы получим HTTP-статус 405 (метод не разрешен) .

4. Настройка поддерживаемых методов HTTP

Аннотация @RestResource также дает нам возможность настроить URL-адрес, сопоставленный с методом репозитория, и идентификатор ссылки в JSON, возвращаемый при обнаружении ресурсов HATEOAS .

Для этого мы используем необязательные параметры аннотации:

  • путь для URL-адреса
  • rel для идентификатора ссылки

Вернемся к нашему UserRepository и добавим простой метод findByEmail :

WebsiteUser findByEmail(@Param("email") String email);

Выполнив cUrl для http ://localhost:8080/users/search/ , мы теперь можем увидеть наш новый метод в списке других ресурсов:

{
"_links": {
"findByEmail": {
"href": "http://localhost:8080/users/search/findByEmail{?email}"
},
"self": {
"href": "http://localhost:8080/users/search/"
}
}
}

Если нам не нравится путь по умолчанию, вместо изменения метода репозитория мы можем просто добавить аннотацию @RestResource :

@RestResource(path = "byEmail", rel = "customFindMethod")
WebsiteUser findByEmail(@Param("email") String email);

И если мы снова сделаем обнаружение ресурсов, полученный JSON подтвердит наши изменения:

{
"_links": {
"customFindMethod": {
"href": "http://localhost:8080/users/search/byEmail{?email}",
"templated": true
},
"self": {
"href": "http://localhost:8080/users/search/"
}
}
}

5. Программная конфигурация

Иногда нам нужен более тонкий уровень конфигурации, чтобы открыть или ограничить доступ к нашим HTTP-методам. Например, POST для ресурсов коллекции, а также PUT и PATCH для ресурсов элементов используют один и тот же метод сохранения .

Начиная с Spring Data REST 3.1 и доступного с Spring Boot 2.1 , мы можем изменить экспозицию определенного метода HTTP через класс ExposureConfiguration . Этот конкретный класс конфигурации предоставляет API на основе лямбда для определения как глобальных правил, так и правил на основе типов.

Например, мы можем использовать ExposureConfiguration для ограничения запросов PATCH к UserRepository :

public class RestConfig implements RepositoryRestConfigurer {
@Override
public void configureRepositoryRestConfiguration(RepositoryRestConfiguration restConfig,
CorsRegistry cors) {
ExposureConfiguration config = restConfig.getExposureConfiguration();
config.forDomainType(WebsiteUser.class).withItemExposure((metadata, httpMethods) ->
httpMethods.disable(HttpMethod.PATCH));
}
}

6. Заключение

В этой статье мы рассмотрели, как мы можем настроить Spring Data REST для настройки методов HTTP, поддерживаемых по умолчанию в наших ресурсах.

Как обычно, примеры, использованные в этой статье, можно найти в нашем проекте на GitHub .