Правильный, RESTful способ спроектировать конечную точку для неточной фильтрации - PullRequest
Новая
       9

Правильный, RESTful способ спроектировать конечную точку для неточной фильтрации

0 голосов
/ 11 декабря 2018

Допустим, у меня есть конечные точки для GET /objects/{id}, GET /objects/{code} и POST /objects, как предписано RESTful design, и objects имеют поля name и code (уникальные).

Я хочу использовать данные objects в другом приложении, особенно с фильтрацией автозаполнения как на name, так и на code.

На мой взгляд, параметры

  • GET /objects?q={user-input} где q - это то, что печатает пользователь, а бэкэнд выполняет инструкцию SELECT с LIKE '%{user-input}%'
  • POST /objects/search с полезной нагрузкой JSON

Что является более RESTful?Есть ли другие варианты?

1 Ответ

0 голосов
/ 12 декабря 2018

Это зависит от моей цели.

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

  • GET /objects/autocomplete?prefix=<>

Это может выглядеть странно, поскольку это вовсе не RESTful, но моя цель - сделать простую и конкретную конечную точку, на случай, если этовсе ваше приложение примерно.

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

  • POST /objects/search

И то, и другое не обязательно очень RESTful, и, на мой взгляд, REST не всегда лучшая стратегия, более важным является вариант использования.В любом случае, объект "cruding" и действия с отношениями (RESTful), поэтому я бы оставил их нетронутыми, поэтому вы можете предпочесть /objects/search вместо /objects (как в GET, так и в POST), чтобы убедиться, что вы этого не сделаетевлияет на домен.

Подробнее вы можете прочитать здесь: https://softwareengineering.stackexchange.com/questions/353086/what-is-a-proper-way-to-do-a-complex-restful-search-method

...