#java #spring-boot #rest #oop #design-patterns
#java #весенняя загрузка #остальное #ооп #шаблоны проектирования
Вопрос:
Мне любопытно, есть ли лучший способ справиться с расширенным дизайном фильтра. У меня есть API для музыкального каталога, который позволяет пользователям искать треки на основе следующих критериев (если ничего не указано, он просто возвращает разбитый на страницы результат всех треков, упорядоченных по добавленной дате)
это означает базовую конечную точку чего-то вроде http://www.myapi.com/api/tracks Затем я предлагаю следующие параметры, позволяющие осуществлять расширенную фильтрацию на основе нескольких факторов, если они захотят это сделать. Если параметр не указан, он вообще не включается в запрос.
Имя исполнителя / Название песни
Жанр (ы)
Ключ (ы)
Диапазон BPM
Тип (ы) версии
Например, вы можете искать рок-песни, которые находятся в ключе 2A, и будут возвращены все песни, которые соответствуют этим критериям. Тогда конечная точка будет выглядеть примерно так:
http://www.myapi.com/api/tracks?genres=ROCKamp;keys=2A
Мой вопрос заключается в том, что при разработке чего-то подобного существует ли какой-либо другой подход, кроме настройки вашей конечной точки в основном для перебора всех возможных комбинаций параметров запроса и создания отдельного запроса в основном для каждой комбинации?
Когда я думаю об этом, я думаю о чем-то вроде расширенного фильтра Linkedin… конечно, они не могут перебирать такие вещи, было бы ужасно поддерживать и масштабировать. Как такая функциональность обычно реализуется в производственных системах?
Комментарии:
1. Параметры запроса URL динамичны по своей природе, и вы можете передавать через них практически все. Единственная конечная точка, которая вам нужна
.../api/tracks, — это то, что будет иметь некоторые сопоставления между параметрами запроса URL и строковыми переменными, которые вы можете передать в хранилище данных. Вообще не нужна «грубая сила» (эта «грубая сила» потерпит неудачу в simplehttp://www.myapi.com/api/tracks?genres=ROCKamp;keys=2Aиhttp://www.myapi.com/api/tracks?keys=2Aamp;genres=ROCKright?).2. @пушистый не совсем. Я понимаю, что часть о динамических параметрах запроса. Я был более заинтересован в том, чтобы сразу получить запрос, а затем вы хотите передать их в хранилище данных. Например, скажем, например, я прохожу через приведенный выше пример, не имеет значения порядок передаваемых параметров, но если бы я изменил его, включив дополнительный параметр для поиска по названию исполнителя / песни, для этого потребовался бы другой запрос для репозитория данных, но с 5фильтры и несколько комбинаций параметров, которые могут быть включены, что означает множество запросов в хранилище данных
3. Вы могли бы просто динамически создавать запрос на основе того, какие параметры передаются. Конечно, такой крупный сайт, как LinkedIn, решил бы эту проблему совсем иначе, чем небольшой API, поддерживаемый СУБД.
4. @fluffy Мне, по сути, понадобился бы запрос репозитория данных, если включен ключ / жанр, а затем один для поиска / ключа / жанра… затем один для bpmRange / genre, а затем один для search / bpmRange / genre и т. Д. Я просто подумал, что это не может быть так, как это реализовано в производственных системах.
5. @oznomal Я в замешательстве, так что ваша главная забота заключается не в параметрах запроса URL, а в создании запроса динамического фильтра к базовому источнику данных?