А как заставить ноутбук автоматически включиться после продолжительного отсутствия электропитания, когда батарейка успела разрядится? В этом плане штуки вроде Raspberry выглядят надёжнее.
AX3 из коробки идут с 7-ой версией и с новой реализацией пакета для работы с WiFi (который в UI так и называется "WiFi" вместо старого "Wireless"). Поэтому на AX3 не должно быть вообще каких-то проблем, т.к. нет ни какой "миграции" при обновлении.
В вашем примере всё таки есть синхронизация серверов, хоть и медленная. Значит эту задачу можно решить с использованием грамотного UI на клиенте. Который сможет донести до юзера информацию, что его запрос всё ещё находится в обработке и надо подождать. Можно ведь рассчитать максимальное время, требуемое на синхронизацию серверов и сообщить клиенту в ответе на первый запрос, сколько времени надо что бы информация о состоянии задачи была достпна на всех серверах.
Нельзя использовать гео-балансировку по DNS? Это что за такое странное требование к гео-распределённому сервису? Ок, если на один домен - один адрес, тогда можно сделать 100500 доменов. А что не так с тем что балансировщик знает про все шарды? Если у вас в домене только один адрес, а серверов много, то очевидно придётся делать на этом адресе балансер по всем серверам.
И ещё раз повторю - эти проблемы не имеют ни какого отношения к stateless из REST. Stateless ни помогает их решить, ни делает их решение сложнее.
Всё это имеет отношение только к тому как реализовать доступ клиента к результатам запроса, которые очень долго генерируются. И тут нет серебрянной пули. Особенно если, метафорически, запрос клиент послает в гугл, а результат ожидает от яндекса.
Так проблема в рандомной балансировке + отсутствии или очень медленной репликации данных. Надо либо сделать умный роутинг запроса, что бы он направлялся в нужный сервер, а не в рандомный (всё уже придумано до нас и есть разные варианты). Либо обеспечить быструю репликацию базы данных на все сервера, но это несколько примитивный способ, который будет в пустую тратить ресурсы.
PS: SOAP - как раз таки stateful протокол, но к данной проблеме это ни как не относится. Точно такую же проблему можно получить с чем угодно, если не поавильно спроектировать архитектуру под условия гео-распределённого сервиса.
А если пуш не дойдёт до клиента, что тогда делать? Видимо сохранить сообщение на сервере (желательно персистентно если это важное сообщение), придумать как определять, что нужный клиент вернулся и запушить ему повторно, даже если клиенту уже не нужно это сообщение. Т.е. получается то же самое только в профиль. Пушинг или пулинг - это разные подходы для решения одной задачи. Они имеют свои плюсы и свои минусы. Пулинг проще реализовать, особенно на серверной стороне. Пушинг обеспечивает более быструю доставку информации до клиента, меньше тратит трафика, но требует более сложных решений на сервере и клиенте.
И какие ограничения в масштабировании накладывает stateless? По мне так наоборот становится проще - не надо решать пачку проблем для обеспечения работы в statefull режиме. В stateless вообще же ничего не надо делать специального. Принял запрос, достал из него "инструкции", выполнил, вернул ответ и забыл.
"Асинхронные" запросы поверх rest ничем не отличаются от других. Мы создали какой-то ресурс в сервисе и позднее запрашиваем состояние этого ресурса. Обычная рутина для любого api. А послать запрос и ждать ответ пока не вернёт - это вообще почти не рабочая схема в условиях работы с сетью, т.к. в любой момент связь может прерваться. А значит, что-бы это решить, придётся на клиенте запоминать какой-то уникальный идентификатор, что бы после реконекта запросить у сервера результат обработки своего запроса. Т.е. мы сделаем то же самое что и в "асинхронных" запросах.
Вы продолжаете какую-то другую задачу решать. Stateless не про то что любой сервер в кластере должен уметь обработать запрос клиента. Он только про то, что клиент должен передать в запросе всю информацию, которая нужна, что бы сервис мог обработать этот запрос. Какой именно сервер будет обрабатывать запрос, и должн ли быть это любой сервер в кластере - это не относится к тому, что подразумевается под stateless в REST. Это другая задача, которая имеет разные решения. Начиная от полной, синхронной репликации базы продолжая шардированием с "умным" роутингом до нужной шарды и заканчивая такой реализацией где вообще не нужна база данных и любой сервер может обработать запрос клиента.
С учётом того, что репрезентация ресурса может быть совершенно разной, то я не думаю, что Филдинг закладывал в REST ограничение на то, что может возвращать и принимать сервер. В самом класическом виде сервер может возвращать ресурс в виде html страницы, а принимать его в виде html формы. Так же ресурс может возвращаться сервером как картинка (например график), а создаваться передачей json-а со списком точек. Это всё настолько "особенности реализации", что не стоят упоминания в фундаментальных ограничениях архитектуры (даже не приложения или протокола), которые разработал Филдинг.
Такие доп. ограничения можно вводить самостоятельно из соображений удобства разработки конкретного приложения. Например с ними проще сделать фреймворк. Но я не считаю их фундаментальными, что бы строго следовать им в любом приложении, которое претендует на тег "REST".
Я не вижу в вашей цитате Филдинга ограничение на то, что репрезентация передаваемая клиентом на сервер должна быть ограничена репрезентацией, которую возвращает сервер клиенту. Не думаю что это хоть чем-то важно в контексте REST
Вы немного про другое спрашиваете. Можно ли получить состояние от другого сервера или нет - это не имеет отношения к stateless. Stateless исключительно про то, что клиент должен в своём запросе передать всю необходимую информацию, что бы сервер мог его обработать. Вот пример общения которое рассчитано на наличие стейта между клиентом и сервером: Q: Сколько продуктовых магазино в Магадане? A: 543 Q: А сколько обувных? A: 100
Видите где тут стейт? Второй запрос не содержит "фильтра" по городам (в Магадане). Но т.к. сервер помнит стейт, то отвечает правильно.
Сделать такое не просто, если у нас больше одного сервера. Надо уметь определять в рамках какой сессии пришёл запрос от клиента. Надо как-то хранить "сессию" и как-то удалять её когда протухла. А клиент может создать 100500 сессий. Надо сделать эту сессию доступной на других серверах или обеспечить роутинг запроса так, что бы он попадал на те сервера где есть его сессия.
Примером "ужасного" протокола с состоянием является FTP - что бы попасть в какую-то папку надо по очереди послать команды на перемещение в следующую дочернюю папку. Сервер при этом помнит где находится клиент. После этого клиент может что-то делать в папке, в которую "зашёл". Если случиться разрыв связи, то клиенту придётся опять повторять всё что он делал до этого - пересещаться постепенно в нужную папку.
Не думаю, что это определение запрещает передать, что-то дополнительное, что не является прямым отражением на поля ресурса в базе данных или ещё где хранится ресурсв. Репрезентация может иметь любой вид как по форме так и по содержанию. На то она и репрезентация сущности, а не сама сущность. Например у ресурса может быть поле published с датой публикации. Но мы не хотим давать клиентам менять его напрямую. Для этого клиент может передавать "виртуальное" поле is_published: bool, а уже сервер будет в зависимости от него менять значение поля published.
stateles относится к тому, что клиент не должен рассчитывать на то, что сервер помнит его предыдущие запросы. Каждый новый запрос клиента должен содержать достаточно информации, что бы сервер мог его обработать. К серверу, в общем случае, это тоже относится - он не должен рассчитывать на то, что клиент помнит предыдущие ответы, он просто возвращает то что попросил клиент в текущем запросе. Такой подход как раз позволяет упростить масштабирование сервиса, т.к. нам не надо реплицировать "знание" о предыдущих запросах на все сервера, куда может прийти запрос клиента (вы сами привели этот довод на примере сотовых станций).
Рассмотрим ваш пример в условиях гео-распределённого сервиса. Первый запрос клиента создаёт задачу, сервис возвращает URL этой задачи. После чего клиент по этому URL-у запрашивает состояние задачи. И вот тут уже видно отсутствие "состояния". Клиент не держит открытым TCP конект, через который задача была создана, что бы через этот конект потом получать состояние этой задачи. Вместо этого клиент может создать новый конект и передать туда запрос с URL-ом. И этого URL-а будет достаточно сервису, что бы понять куда в большом кластере надо направить запрос для обработки. Во первых роутинг произойдёт на уровне DNS, направив запрос в тот дата-центр, где задача была создана. Далее, балансировщик в ДЦ по URL-у определит какая "шарда" хранит в себе информацию об этой задаче и отправит запрос туда. В результате нет ни какой необходимости делать реплики для базы данных. Можно обойтись лучше масштабируемым вариантом - шардированием.
Так же декларация использования stateless сообщает нам о том, что мы должны соответствующим образом вести разработку клиента. Клиент должен "понимать", что любой его запрос может завершиться не так как он ожидает, из-за того что сервис не гарантирует ему, что состояние его базы данных совпадает с "ожиданием" клиента. Хотя это скорее не про stateless, а общий принцип разработки мульти-пользовательских сервисов.
данные, которые в REST должны быть подмножеством полей ресурса.
Нет в REST (rest api, если быть точным) такого ограничения. От куда всего его выдумывают? Передавайте что хотите. Тут исключительно вопрос удобства реализации, тестирования, документирования и поддержки всего этого дела. В общем случае просто получается удобнее, если то что возвращает GET можно потом отправить в PATCH. И фреймворки писать удобнее, когда у нас есть супер жёсткие ограничения. Можно тогда свести весь код приложения к минимуму - указал фреймворку на таблицу в базе данных, а остальное он всё сам сделает.
Не такой и специфичный. Он, если не ошибаюсь, даже описан в спеке на HTTP. Там так и сказано про 404, что сервер может возвращать его по любой причине из-за которой нельзя дать понять клиенту, что указанный в URL ресурс существует на сервере. Как пример - отсутствие у клиента прав доступа к ресурсу для которого один факт его наличия на сервере раскрывает приватную информацию. Например если ID ресурса - это любой, публично известный идентификатор человека.
А возвращать 401/403 на любой чих - это, по моему, довольно таки довольно специфичное решение, которое не всегда удобно. Чаще всё таки нет проблем, с тем, что бы клиент без прав доступа узнал, что ресурс на который он стучится - отсутствует.
При этом также должен меняться статус статьи, которая является другим ресурсом, а это не соответствует принципам REST.
В REST нет такого, там как раз максимально всё говорит о том, что клиент не должен рассчитывать на какое-то состояние на сервере. Это состояние может измениться там в любое время и по любой причине. Сам сервер может изменить что-то по крон-таске, а может прийти запрос от другого клиента и внести изменения. Нет никакого запрета на то, что бы приложение на сервере изменило другие сущности в процессе создания/изменения сущности, которую попросил изменить клиент в текущем запросе.
Не вижу разницы в сложности межу тем, что бы создать 20 уникальных глаголов для двух сущностей, или создать 10 сущностей с 4-мя универсальными глаголами. Уровень сложности на бекенде в общем случае получится тот же самый. Но второй вариант, за счёт унификации интерфейса и использования функционала хорошо документированного протокола HTTP, позволяет быстрее в нём разобраться тем, кто знает про HTTP, но в первый раз видит ваш API. А это очень важный показатель. Никто ведь не берёт первого попавшегося C++ разработчика, на проект написанный на питоне. И в первую очередь, при прочих равных, предпочтение будут отдавать тем кандидатам, которые знакомы с технологиями и принципами, которые используются в проекте. В этом контексте использование широкоизвестных и документированных технологий и протоколов облегчит поддержку проекта, в отличии от чего-то самописного, которое, как часто бывает, ещё и не описано в документации.
если бизнес использует не существительное "Публикация", а глагол "Опубликовать"
А вас не соответствие бизнес-глаголов с сущностями смущает только на уровне API? На уровне базы данных вас не коробит, что там по сути только одни сущности, и ни один глагол не совпадает с тем, что написано в бизнес-требованиях?
По идее, get запрос предназначен что бы получить состояние ресурса на который указывает url, например /users. Получение в этом же ответе списка состояний дочерних ресурос (/users/<user_id>) - это уже доп.функционал, который не обязательно реализовывать в рамках get запроса к ресурсу-контейнеру. Если ваши запросы простые, быстро выполняются, тогда можно использовать get к контейнеру. Если же у вас это что-то сложное, с достаточной вероятностью непредсказуемо долгого времени выполнения, то лучше под это предусмотреть отдельное api. Такое как выше описали - отдельный ресрус "поисковые_запросы", который будет через post создавать ресурсы "запрос", в котором будут возвращаться результаты поиска. При этом не обязательно этот "запрос" сохранять в базу данных, если это не требуется на первых порах. Главное что, api уже поддерживает такую возможность, и в будущем, при усложнении поиска, можно будет реализовать полностью "асинхронную" схему работы поиска не меняя api.
А как заставить ноутбук автоматически включиться после продолжительного отсутствия электропитания, когда батарейка успела разрядится? В этом плане штуки вроде Raspberry выглядят надёжнее.
AX3 из коробки идут с 7-ой версией и с новой реализацией пакета для работы с WiFi (который в UI так и называется "WiFi" вместо старого "Wireless"). Поэтому на AX3 не должно быть вообще каких-то проблем, т.к. нет ни какой "миграции" при обновлении.
В вашем примере всё таки есть синхронизация серверов, хоть и медленная. Значит эту задачу можно решить с использованием грамотного UI на клиенте. Который сможет донести до юзера информацию, что его запрос всё ещё находится в обработке и надо подождать. Можно ведь рассчитать максимальное время, требуемое на синхронизацию серверов и сообщить клиенту в ответе на первый запрос, сколько времени надо что бы информация о состоянии задачи была достпна на всех серверах.
Нельзя использовать гео-балансировку по DNS? Это что за такое странное требование к гео-распределённому сервису? Ок, если на один домен - один адрес, тогда можно сделать 100500 доменов.
А что не так с тем что балансировщик знает про все шарды? Если у вас в домене только один адрес, а серверов много, то очевидно придётся делать на этом адресе балансер по всем серверам.
И ещё раз повторю - эти проблемы не имеют ни какого отношения к stateless из REST. Stateless ни помогает их решить, ни делает их решение сложнее.
Всё это имеет отношение только к тому как реализовать доступ клиента к результатам запроса, которые очень долго генерируются. И тут нет серебрянной пули. Особенно если, метафорически, запрос клиент послает в гугл, а результат ожидает от яндекса.
Так проблема в рандомной балансировке + отсутствии или очень медленной репликации данных. Надо либо сделать умный роутинг запроса, что бы он направлялся в нужный сервер, а не в рандомный (всё уже придумано до нас и есть разные варианты). Либо обеспечить быструю репликацию базы данных на все сервера, но это несколько примитивный способ, который будет в пустую тратить ресурсы.
PS: SOAP - как раз таки stateful протокол, но к данной проблеме это ни как не относится. Точно такую же проблему можно получить с чем угодно, если не поавильно спроектировать архитектуру под условия гео-распределённого сервиса.
А если пуш не дойдёт до клиента, что тогда делать? Видимо сохранить сообщение на сервере (желательно персистентно если это важное сообщение), придумать как определять, что нужный клиент вернулся и запушить ему повторно, даже если клиенту уже не нужно это сообщение. Т.е. получается то же самое только в профиль.
Пушинг или пулинг - это разные подходы для решения одной задачи. Они имеют свои плюсы и свои минусы. Пулинг проще реализовать, особенно на серверной стороне. Пушинг обеспечивает более быструю доставку информации до клиента, меньше тратит трафика, но требует более сложных решений на сервере и клиенте.
И какие ограничения в масштабировании накладывает stateless? По мне так наоборот становится проще - не надо решать пачку проблем для обеспечения работы в statefull режиме.
В stateless вообще же ничего не надо делать специального. Принял запрос, достал из него "инструкции", выполнил, вернул ответ и забыл.
"Асинхронные" запросы поверх rest ничем не отличаются от других. Мы создали какой-то ресурс в сервисе и позднее запрашиваем состояние этого ресурса. Обычная рутина для любого api.
А послать запрос и ждать ответ пока не вернёт - это вообще почти не рабочая схема в условиях работы с сетью, т.к. в любой момент связь может прерваться. А значит, что-бы это решить, придётся на клиенте запоминать какой-то уникальный идентификатор, что бы после реконекта запросить у сервера результат обработки своего запроса. Т.е. мы сделаем то же самое что и в "асинхронных" запросах.
Вы продолжаете какую-то другую задачу решать. Stateless не про то что любой сервер в кластере должен уметь обработать запрос клиента. Он только про то, что клиент должен передать в запросе всю информацию, которая нужна, что бы сервис мог обработать этот запрос.
Какой именно сервер будет обрабатывать запрос, и должн ли быть это любой сервер в кластере - это не относится к тому, что подразумевается под stateless в REST. Это другая задача, которая имеет разные решения. Начиная от полной, синхронной репликации базы продолжая шардированием с "умным" роутингом до нужной шарды и заканчивая такой реализацией где вообще не нужна база данных и любой сервер может обработать запрос клиента.
С учётом того, что репрезентация ресурса может быть совершенно разной, то я не думаю, что Филдинг закладывал в REST ограничение на то, что может возвращать и принимать сервер.
В самом класическом виде сервер может возвращать ресурс в виде html страницы, а принимать его в виде html формы. Так же ресурс может возвращаться сервером как картинка (например график), а создаваться передачей json-а со списком точек.
Это всё настолько "особенности реализации", что не стоят упоминания в фундаментальных ограничениях архитектуры (даже не приложения или протокола), которые разработал Филдинг.
Такие доп. ограничения можно вводить самостоятельно из соображений удобства разработки конкретного приложения. Например с ними проще сделать фреймворк. Но я не считаю их фундаментальными, что бы строго следовать им в любом приложении, которое претендует на тег "REST".
Я не вижу в вашей цитате Филдинга ограничение на то, что репрезентация передаваемая клиентом на сервер должна быть ограничена репрезентацией, которую возвращает сервер клиенту. Не думаю что это хоть чем-то важно в контексте REST
Вы немного про другое спрашиваете. Можно ли получить состояние от другого сервера или нет - это не имеет отношения к stateless.
Stateless исключительно про то, что клиент должен в своём запросе передать всю необходимую информацию, что бы сервер мог его обработать.
Вот пример общения которое рассчитано на наличие стейта между клиентом и сервером:
Q: Сколько продуктовых магазино в Магадане?
A: 543
Q: А сколько обувных?
A: 100
Видите где тут стейт? Второй запрос не содержит "фильтра" по городам (в Магадане). Но т.к. сервер помнит стейт, то отвечает правильно.
Сделать такое не просто, если у нас больше одного сервера. Надо уметь определять в рамках какой сессии пришёл запрос от клиента. Надо как-то хранить "сессию" и как-то удалять её когда протухла. А клиент может создать 100500 сессий. Надо сделать эту сессию доступной на других серверах или обеспечить роутинг запроса так, что бы он попадал на те сервера где есть его сессия.
Примером "ужасного" протокола с состоянием является FTP - что бы попасть в какую-то папку надо по очереди послать команды на перемещение в следующую дочернюю папку. Сервер при этом помнит где находится клиент. После этого клиент может что-то делать в папке, в которую "зашёл". Если случиться разрыв связи, то клиенту придётся опять повторять всё что он делал до этого - пересещаться постепенно в нужную папку.
Не думаю, что это определение запрещает передать, что-то дополнительное, что не является прямым отражением на поля ресурса в базе данных или ещё где хранится ресурсв. Репрезентация может иметь любой вид как по форме так и по содержанию. На то она и репрезентация сущности, а не сама сущность.
Например у ресурса может быть поле published с датой публикации. Но мы не хотим давать клиентам менять его напрямую. Для этого клиент может передавать "виртуальное" поле is_published: bool, а уже сервер будет в зависимости от него менять значение поля published.
stateles относится к тому, что клиент не должен рассчитывать на то, что сервер помнит его предыдущие запросы. Каждый новый запрос клиента должен содержать достаточно информации, что бы сервер мог его обработать. К серверу, в общем случае, это тоже относится - он не должен рассчитывать на то, что клиент помнит предыдущие ответы, он просто возвращает то что попросил клиент в текущем запросе.
Такой подход как раз позволяет упростить масштабирование сервиса, т.к. нам не надо реплицировать "знание" о предыдущих запросах на все сервера, куда может прийти запрос клиента (вы сами привели этот довод на примере сотовых станций).
Рассмотрим ваш пример в условиях гео-распределённого сервиса. Первый запрос клиента создаёт задачу, сервис возвращает URL этой задачи. После чего клиент по этому URL-у запрашивает состояние задачи. И вот тут уже видно отсутствие "состояния". Клиент не держит открытым TCP конект, через который задача была создана, что бы через этот конект потом получать состояние этой задачи. Вместо этого клиент может создать новый конект и передать туда запрос с URL-ом. И этого URL-а будет достаточно сервису, что бы понять куда в большом кластере надо направить запрос для обработки. Во первых роутинг произойдёт на уровне DNS, направив запрос в тот дата-центр, где задача была создана. Далее, балансировщик в ДЦ по URL-у определит какая "шарда" хранит в себе информацию об этой задаче и отправит запрос туда.
В результате нет ни какой необходимости делать реплики для базы данных. Можно обойтись лучше масштабируемым вариантом - шардированием.
Так же декларация использования stateless сообщает нам о том, что мы должны соответствующим образом вести разработку клиента. Клиент должен "понимать", что любой его запрос может завершиться не так как он ожидает, из-за того что сервис не гарантирует ему, что состояние его базы данных совпадает с "ожиданием" клиента. Хотя это скорее не про stateless, а общий принцип разработки мульти-пользовательских сервисов.
Нет в REST (rest api, если быть точным) такого ограничения. От куда всего его выдумывают?
Передавайте что хотите. Тут исключительно вопрос удобства реализации, тестирования, документирования и поддержки всего этого дела.
В общем случае просто получается удобнее, если то что возвращает GET можно потом отправить в PATCH.
И фреймворки писать удобнее, когда у нас есть супер жёсткие ограничения. Можно тогда свести весь код приложения к минимуму - указал фреймворку на таблицу в базе данных, а остальное он всё сам сделает.
Не такой и специфичный. Он, если не ошибаюсь, даже описан в спеке на HTTP. Там так и сказано про 404, что сервер может возвращать его по любой причине из-за которой нельзя дать понять клиенту, что указанный в URL ресурс существует на сервере. Как пример - отсутствие у клиента прав доступа к ресурсу для которого один факт его наличия на сервере раскрывает приватную информацию. Например если ID ресурса - это любой, публично известный идентификатор человека.
А возвращать 401/403 на любой чих - это, по моему, довольно таки довольно специфичное решение, которое не всегда удобно. Чаще всё таки нет проблем, с тем, что бы клиент без прав доступа узнал, что ресурс на который он стучится - отсутствует.
В REST нет такого, там как раз максимально всё говорит о том, что клиент не должен рассчитывать на какое-то состояние на сервере. Это состояние может измениться там в любое время и по любой причине. Сам сервер может изменить что-то по крон-таске, а может прийти запрос от другого клиента и внести изменения.
Нет никакого запрета на то, что бы приложение на сервере изменило другие сущности в процессе создания/изменения сущности, которую попросил изменить клиент в текущем запросе.
Не вижу разницы в сложности межу тем, что бы создать 20 уникальных глаголов для двух сущностей, или создать 10 сущностей с 4-мя универсальными глаголами. Уровень сложности на бекенде в общем случае получится тот же самый.
Но второй вариант, за счёт унификации интерфейса и использования функционала хорошо документированного протокола HTTP, позволяет быстрее в нём разобраться тем, кто знает про HTTP, но в первый раз видит ваш API. А это очень важный показатель. Никто ведь не берёт первого попавшегося C++ разработчика, на проект написанный на питоне. И в первую очередь, при прочих равных, предпочтение будут отдавать тем кандидатам, которые знакомы с технологиями и принципами, которые используются в проекте. В этом контексте использование широкоизвестных и документированных технологий и протоколов облегчит поддержку проекта, в отличии от чего-то самописного, которое, как часто бывает, ещё и не описано в документации.
А вас не соответствие бизнес-глаголов с сущностями смущает только на уровне API? На уровне базы данных вас не коробит, что там по сути только одни сущности, и ни один глагол не совпадает с тем, что написано в бизнес-требованиях?
По идее, get запрос предназначен что бы получить состояние ресурса на который указывает url, например /users. Получение в этом же ответе списка состояний дочерних ресурос (/users/<user_id>) - это уже доп.функционал, который не обязательно реализовывать в рамках get запроса к ресурсу-контейнеру.
Если ваши запросы простые, быстро выполняются, тогда можно использовать get к контейнеру. Если же у вас это что-то сложное, с достаточной вероятностью непредсказуемо долгого времени выполнения, то лучше под это предусмотреть отдельное api. Такое как выше описали - отдельный ресрус "поисковые_запросы", который будет через post создавать ресурсы "запрос", в котором будут возвращаться результаты поиска. При этом не обязательно этот "запрос" сохранять в базу данных, если это не требуется на первых порах. Главное что, api уже поддерживает такую возможность, и в будущем, при усложнении поиска, можно будет реализовать полностью "асинхронную" схему работы поиска не меняя api.