«Язык запросов REST со спецификациями Spring Data JPA»

«1. Обзор

В этом руководстве мы создадим REST API поиска/фильтрации с использованием Spring Data JPA и спецификаций.

Мы начали рассматривать язык запросов в первой статье этой серии — с решения, основанного на критериях JPA.

Итак, почему язык запросов? Потому что — для любого достаточно сложного API — поиска/фильтрации ваших ресурсов по очень простым полям просто недостаточно. Язык запросов является более гибким и позволяет вам отфильтровывать именно те ресурсы, которые вам нужны.

2. Сущность пользователя

Сначала — давайте начнем с простой сущности пользователя для нашего API поиска:

@Entity
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    private String firstName;
    private String lastName;
    private String email;

    private int age;
    
    // standard getters and setters
}

3. Фильтр с использованием спецификации

Теперь — давайте перейдем непосредственно к самому интересная часть проблемы — запросы с пользовательскими спецификациями Spring Data JPA.

Мы создадим UserSpecification, который реализует интерфейс Specification, и мы собираемся передать наше собственное ограничение для построения фактического запроса:

public class UserSpecification implements Specification<User> {

    private SearchCriteria criteria;

    @Override
    public Predicate toPredicate
      (Root<User> root, CriteriaQuery<?> query, CriteriaBuilder builder) {
 
        if (criteria.getOperation().equalsIgnoreCase(">")) {
            return builder.greaterThanOrEqualTo(
              root.<String> get(criteria.getKey()), criteria.getValue().toString());
        } 
        else if (criteria.getOperation().equalsIgnoreCase("<")) {
            return builder.lessThanOrEqualTo(
              root.<String> get(criteria.getKey()), criteria.getValue().toString());
        } 
        else if (criteria.getOperation().equalsIgnoreCase(":")) {
            if (root.get(criteria.getKey()).getJavaType() == String.class) {
                return builder.like(
                  root.<String>get(criteria.getKey()), "%" + criteria.getValue() + "%");
            } else {
                return builder.equal(root.get(criteria.getKey()), criteria.getValue());
            }
        }
        return null;
    }
}

Как мы видим, мы создаем Specification на основе некоторые простые ограничения, которые мы представляем в следующем классе «SearchCriteria»:

public class SearchCriteria {
    private String key;
    private String operation;
    private Object value;
}

Реализация SearchCriteria содержит базовое представление ограничения — и на основе этого ограничения мы собираемся построить запрос :

ключ: имя поля — например, firstName, age, … и т. д. операция: операция — например, равенство, меньше, … и т. д. значение: значение поля â – например, john, 25, … и т. д.

Конечно, реализация упрощена и может быть улучшена; однако это прочная основа для необходимых нам мощных и гибких операций.

4. Пользовательский репозиторий

Далее — давайте взглянем на пользовательский репозиторий; мы просто расширяем JpaSpecificationExecutor, чтобы получить новые API спецификаций:

public interface UserRepository 
  extends JpaRepository<User, Long>, JpaSpecificationExecutor<User> {}

5. Протестируйте поисковые запросы

Теперь давайте протестируем новый API поиска.

Во-первых, давайте создадим несколько пользователей, чтобы они были готовы к запуску тестов:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = { PersistenceJPAConfig.class })
@Transactional
@TransactionConfiguration
public class JPASpecificationsTest {

    @Autowired
    private UserRepository repository;

    private User userJohn;
    private User userTom;

    @Before
    public void init() {
        userJohn = new User();
        userJohn.setFirstName("John");
        userJohn.setLastName("Doe");
        userJohn.setEmail("[email protected]");
        userJohn.setAge(22);
        repository.save(userJohn);

        userTom = new User();
        userTom.setFirstName("Tom");
        userTom.setLastName("Doe");
        userTom.setEmail("[email protected]");
        userTom.setAge(26);
        repository.save(userTom);
    }
}

Далее, давайте посмотрим, как найти пользователей с заданной фамилией:

@Test
public void givenLast_whenGettingListOfUsers_thenCorrect() {
    UserSpecification spec = 
      new UserSpecification(new SearchCriteria("lastName", ":", "doe"));
    
    List<User> results = repository.findAll(spec);

    assertThat(userJohn, isIn(results));
    assertThat(userTom, isIn(results));
}

Теперь давайте посмотрим, как найти пользователя с заданными именем и фамилией:

@Test
public void givenFirstAndLastName_whenGettingListOfUsers_thenCorrect() {
    UserSpecification spec1 = 
      new UserSpecification(new SearchCriteria("firstName", ":", "john"));
    UserSpecification spec2 = 
      new UserSpecification(new SearchCriteria("lastName", ":", "doe"));
    
    List<User> results = repository.findAll(Specification.where(spec1).and(spec2));

    assertThat(userJohn, isIn(results));
    assertThat(userTom, not(isIn(results)));
}

Примечание. Мы использовали «где» и «и» для объединения Спецификации.

Далее давайте посмотрим, как найти пользователя с заданной фамилией и минимальным возрастом:

@Test
public void givenLastAndAge_whenGettingListOfUsers_thenCorrect() {
    UserSpecification spec1 = 
      new UserSpecification(new SearchCriteria("age", ">", "25"));
    UserSpecification spec2 = 
      new UserSpecification(new SearchCriteria("lastName", ":", "doe"));

    List<User> results = 
      repository.findAll(Specification.where(spec1).and(spec2));

    assertThat(userTom, isIn(results));
    assertThat(userJohn, not(isIn(results)));
}

Теперь давайте посмотрим, как найти пользователя, которого на самом деле не существует:

@Test
public void givenWrongFirstAndLast_whenGettingListOfUsers_thenCorrect() {
    UserSpecification spec1 = 
      new UserSpecification(new SearchCriteria("firstName", ":", "Adam"));
    UserSpecification spec2 = 
      new UserSpecification(new SearchCriteria("lastName", ":", "Fox"));

    List<User> results = 
      repository.findAll(Specification.where(spec1).and(spec2));

    assertThat(userJohn, not(isIn(results)));
    assertThat(userTom, not(isIn(results)));  
}

Наконец — давайте посмотрим, как найти пользователя, которому известна только часть имени:

@Test
public void givenPartialFirst_whenGettingListOfUsers_thenCorrect() {
    UserSpecification spec = 
      new UserSpecification(new SearchCriteria("firstName", ":", "jo"));
    
    List<User> results = repository.findAll(spec);

    assertThat(userJohn, isIn(results));
    assertThat(userTom, not(isIn(results)));
}

6. Объединить спецификации

Далее — давайте взглянем на комбинирование наших пользовательских спецификаций для использования нескольких ограничений и фильтрации по множеству критериев.

Мы собираемся реализовать конструктор — UserSpecificationsBuilder — для простого и плавного комбинирования спецификаций:

public class UserSpecificationsBuilder {
    
    private final List<SearchCriteria> params;

    public UserSpecificationsBuilder() {
        params = new ArrayList<SearchCriteria>();
    }

    public UserSpecificationsBuilder with(String key, String operation, Object value) {
        params.add(new SearchCriteria(key, operation, value));
        return this;
    }

    public Specification<User> build() {
        if (params.size() == 0) {
            return null;
        }

        List<Specification> specs = params.stream()
          .map(UserSpecification::new)
          .collect(Collectors.toList());
        
        Specification result = specs.get(0);

        for (int i = 1; i < params.size(); i++) {
            result = params.get(i)
              .isOrPredicate()
                ? Specification.where(result)
                  .or(specs.get(i))
                : Specification.where(result)
                  .and(specs.get(i));
        }       
        return result;
    }
}

7. UserController

Наконец — давайте воспользуемся этой новой функцией постоянного поиска/фильтрации. и настройте REST API — создав UserController с помощью простой операции поиска:

@Controller
public class UserController {

    @Autowired
    private UserRepository repo;

    @RequestMapping(method = RequestMethod.GET, value = "/users")
    @ResponseBody
    public List<User> search(@RequestParam(value = "search") String search) {
        UserSpecificationsBuilder builder = new UserSpecificationsBuilder();
        Pattern pattern = Pattern.compile("(\\w+?)(:|<|>)(\\w+?),");
        Matcher matcher = pattern.matcher(search + ",");
        while (matcher.find()) {
            builder.with(matcher.group(1), matcher.group(2), matcher.group(3));
        }
        
        Specification<User> spec = builder.build();
        return repo.findAll(spec);
    }
}

Обратите внимание, что для поддержки других систем, отличных от английского, объект Pattern можно изменить следующим образом:

Pattern pattern = Pattern.compile("(\\w+?)(:|<|>)(\\w+?),", Pattern.UNICODE_CHARACTER_CLASS);

Здесь пример тестового URL для проверки API:

http://localhost:8080/users?search=lastName:doe,age>25

И ответ:

[{
    "id":2,
    "firstName":"tom",
    "lastName":"doe",
    "email":"[email protected]",
    "age":26
}]

t содержат этот символ. Шаблон также не соответствует пробелам.

Если мы хотим искать значения, содержащие запятые, мы можем рассмотреть возможность использования другого разделителя, например «;».

Другим вариантом может быть изменение шаблона для поиска значений между кавычками, а затем удаление их из условия поиска:

Pattern pattern = Pattern.compile("(\\w+?)(:|<|>)(\"([^\"]+)\")");

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

В этом руководстве рассмотрена простая реализация, которая может стать основой для мощный язык запросов REST. Мы хорошо использовали Спецификации данных Spring, чтобы убедиться, что API не привязано к домену, и у нас есть возможность обрабатывать многие другие типы операций.

Полную реализацию этой статьи можно найти в проекте GitHub — это проект на основе Maven, поэтому его легко импортировать и запускать как есть.