«1. Обзор

В этой быстрой статье мы расширим расширенные операции поиска, которые мы реализовали в предыдущей статье, и включим критерии поиска на основе ИЛИ в наш язык запросов REST API.

2. Подход к реализации

Раньше все критерии в параметре поискового запроса образовывали предикаты, сгруппированные только оператором И. Давайте изменим это.

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

При простом подходе мы помечаем критерии, чтобы указать, что они должны быть объединены с помощью оператора ИЛИ.

Например, вот URL-адрес для тестирования API для «firstName OR lastName»:

http://localhost:8080/users?search=firstName:john,'lastName:doe

Обратите внимание, что мы пометили критерий lastName одинарной кавычкой, чтобы различать его. Мы зафиксируем этот предикат для оператора ИЛИ в нашем объекте значения критерия — SpecSearchCriteria:

public SpecSearchCriteria(
  String orPredicate, String key, SearchOperation operation, Object value) {
    super();
    
    this.orPredicate 
      = orPredicate != null
      && orPredicate.equals(SearchOperation.OR_PREDICATE_FLAG);
    
    this.key = key;
    this.operation = operation;
    this.value = value;
}

3. Улучшение UserSpecificationBuilder

Теперь давайте изменим наш построитель спецификаций, UserSpecificationBuilder, чтобы учитывать квалифицированные критерии ИЛИ при построении спецификации. \u003cUser\u003e:

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

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

4. Улучшение UserController

Наконец, давайте настроим новую конечную точку REST в нашем контроллере, чтобы использовать эту функцию поиска с помощью оператора OR. Улучшенная логика синтаксического анализа извлекает специальный флаг, который помогает идентифицировать критерии с помощью оператора ИЛИ:

@GetMapping("/users/espec")
@ResponseBody
public List<User> findAllByOrPredicate(@RequestParam String search) {
    Specification<User> spec = resolveSpecification(search);
    return dao.findAll(spec);
}

protected Specification<User> resolveSpecification(String searchParameters) {
    UserSpecificationsBuilder builder = new UserSpecificationsBuilder();
    String operationSetExper = Joiner.on("|")
      .join(SearchOperation.SIMPLE_OPERATION_SET);
    Pattern pattern = Pattern.compile(
      "(\\p{Punct}?)(\\w+?)("
      + operationSetExper 
      + ")(\\p{Punct}?)(\\w+?)(\\p{Punct}?),");
    Matcher matcher = pattern.matcher(searchParameters + ",");
    while (matcher.find()) {
        builder.with(matcher.group(1), matcher.group(2), matcher.group(3), 
        matcher.group(5), matcher.group(4), matcher.group(6));
    }
    
    return builder.build();
}

5. Живой тест с условием ИЛИ

В этом примере живого теста с новой конечной точкой API мы будем искать для пользователей по имени «john» ИЛИ по фамилии «doe». Обратите внимание, что параметр lastName имеет одинарную кавычку, которая квалифицирует его как «предикат ИЛИ»:

private String EURL_PREFIX
  = "http://localhost:8082/spring-rest-full/auth/users/espec?search=";

@Test
public void givenFirstOrLastName_whenGettingListOfUsers_thenCorrect() {
    Response response = givenAuth().get(EURL_PREFIX + "firstName:john,'lastName:doe");
    String result = response.body().asString();

    assertTrue(result.contains(userJohn.getEmail()));
    assertTrue(result.contains(userTom.getEmail()));
}

6. Проверка сохраняемости с условием ИЛИ

Теперь давайте проведем тот же тест, который мы сделали выше, для уровень для пользователей с именем «john» ИЛИ фамилией «doe» :

@Test
public void givenFirstOrLastName_whenGettingListOfUsers_thenCorrect() {
    UserSpecificationsBuilder builder = new UserSpecificationsBuilder();

    SpecSearchCriteria spec 
      = new SpecSearchCriteria("firstName", SearchOperation.EQUALITY, "john");
    SpecSearchCriteria spec1 
      = new SpecSearchCriteria("'","lastName", SearchOperation.EQUALITY, "doe");

    List<User> results = repository
      .findAll(builder.with(spec).with(spec1).build());

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

7. Альтернативный подход

В альтернативном подходе мы могли бы предоставить поисковый запрос, более похожий на полное предложение WHERE SQL запрос.

Например, вот URL для более сложного поиска по имени и возрасту:

http://localhost:8080/users?search=( firstName:john OR firstName:tom ) AND age>22

Обратите внимание, что мы разделили отдельные критерии, операторы и группирующие скобки пробелом, чтобы сформировать допустимое инфиксное выражение.

Давайте проанализируем инфиксное выражение с помощью CriteriaParser. Наш CriteriaParser разбивает данное инфиксное выражение на токены (критерии, круглые скобки, операторы И и ИЛИ) и создает для них постфиксное выражение:

public Deque<?> parse(String searchParam) {

    Deque<Object> output = new LinkedList<>();
    Deque<String> stack = new LinkedList<>();

    Arrays.stream(searchParam.split("\\s+")).forEach(token -> {
        if (ops.containsKey(token)) {
            while (!stack.isEmpty() && isHigerPrecedenceOperator(token, stack.peek())) {
                output.push(stack.pop().equalsIgnoreCase(SearchOperation.OR_OPERATOR)
                  ? SearchOperation.OR_OPERATOR : SearchOperation.AND_OPERATOR);
            }
            stack.push(token.equalsIgnoreCase(SearchOperation.OR_OPERATOR) 
              ? SearchOperation.OR_OPERATOR : SearchOperation.AND_OPERATOR);

        } else if (token.equals(SearchOperation.LEFT_PARANTHESIS)) {
            stack.push(SearchOperation.LEFT_PARANTHESIS);
        } else if (token.equals(SearchOperation.RIGHT_PARANTHESIS)) {
            while (!stack.peek().equals(SearchOperation.LEFT_PARANTHESIS)) { 
                output.push(stack.pop());
            }
            stack.pop();
        } else {
            Matcher matcher = SpecCriteraRegex.matcher(token);
            while (matcher.find()) {
                output.push(new SpecSearchCriteria(
                  matcher.group(1), 
                  matcher.group(2), 
                  matcher.group(3), 
                  matcher.group(4), 
                  matcher.group(5)));
            }
        }
    });

    while (!stack.isEmpty()) {
        output.push(stack.pop());
    }
  
    return output;
}

Давайте добавим новый метод в наш построитель спецификаций, GenericSpecificationBuilder, для создания search Спецификация из постфиксного выражения:

    public Specification<U> build(Deque<?> postFixedExprStack, 
        Function<SpecSearchCriteria, Specification<U>> converter) {

        Deque<Specification<U>> specStack = new LinkedList<>();

        while (!postFixedExprStack.isEmpty()) {
            Object mayBeOperand = postFixedExprStack.pollLast();

            if (!(mayBeOperand instanceof String)) {
                specStack.push(converter.apply((SpecSearchCriteria) mayBeOperand));
            } else {
                Specification<U> operand1 = specStack.pop();
                Specification<U> operand2 = specStack.pop();
                if (mayBeOperand.equals(SearchOperation.AND_OPERATOR)) {
                    specStack.push(Specification.where(operand1)
                      .and(operand2));
                }
                else if (mayBeOperand.equals(SearchOperation.OR_OPERATOR)) {
                    specStack.push(Specification.where(operand1)
                      .or(operand2));
                }
            }
        }
        return specStack.pop();

Наконец, давайте добавим еще одну конечную точку REST в наш UserController для анализа сложного выражения с помощью нового CriteriaParser:

@GetMapping("/users/spec/adv")
@ResponseBody
public List<User> findAllByAdvPredicate(@RequestParam String search) {
    Specification<User> spec = resolveSpecificationFromInfixExpr(search);
    return dao.findAll(spec);
}

protected Specification<User> resolveSpecificationFromInfixExpr(String searchParameters) {
    CriteriaParser parser = new CriteriaParser();
    GenericSpecificationsBuilder<User> specBuilder = new GenericSpecificationsBuilder<>();
    return specBuilder.build(parser.parse(searchParameters), UserSpecification::new);
}

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

В этом руководстве мы улучшили наш язык запросов REST, добавив возможность поиска с помощью оператора ИЛИ.

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

Next »

REST Query Language with RSQL

« Previous

REST Query Language – Advanced Search Operations