Как использовать дополнительную функцию сохранения вместе с функцией поиска HTTP API call

Question

Я реализовал конечную точку HTTP / GET для обеспечения функции поиска.Пользователь отправляет условия поиска в параметрах запроса и получает ответ JSON, содержащий все результаты поиска.

Теперь мне нужно добавить новую функцию, т.е. сохранить поиск.Это означает, что пользователь отправляет те же параметры поиска, а также может отправлять логический параметр, скажем save = true .Я должен сохранить поисковый термин в базе данных в этом случае для использования в будущем.Однако этот параметр не является обязательным.

Я запутался в следующих моментах:

1. Изменить такую ​​же конечную точку GET HTTP, добавив дополнительный параметр save в параметрах запроса.
2. Измените ту же конечную точку GET HTTP, но передав параметр сохранения в теле запроса вместо параметров запроса в качестве параметра изменения его внутреннего состояния.
3. Используйте отдельную конечную точку для сохранения параметров с помощью метода POST.

Каков стандартный / приемлемый способ сделать это?

Answer 1

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

Обычно GET используется для получения состояния ресурсов, хотя, как этоМетод определен как safe, его не следует использовать, если для вызываемого ресурса создано определенное состояние, как при сохранении поискового запроса. RFC 7231 далее заявляет, что:

Полезная нагрузка в сообщении запроса GET не имеет определенной семантики;отправка тела полезной нагрузки по запросу GET может привести к тому, что некоторые существующие реализации отклонят запрос.

Поэтому я бы воздержался от варианта № 1 или № 2, поскольку это может нарушить совместимость определенных клиентов.

POST, с другой стороны, определяется в RFC 7231 как

Метод POST запрашивает, чтобы целевой ресурс обработал представление, заключенное в запросе, в соответствии с собственным ресурсом.специфическая семантика.

Поэтому его следует использовать в любой ситуации, когда другие HTTP-операции не подходят.Спецификация HTTP также определяет, что при создании нового ресурса должен быть возвращен код состояния 201 Created HTTP, включая заголовок ответа HTTP с именем Location, содержащий URI созданного ресурса.Этот URI впоследствии может быть использован для получения его состояния (т. Е. Результата выполненного поиска).

С точки зрения клиента вы в основном храните какое-либо определение запроса на сервере и не заботитесь о том, где и как на самом деле находится сервер.сохраняя это.Все, что вам нужно, - это получить дескриптор, который вы позже сможете вызвать.Это не мешает серверу возвращать текущий результат поиска в пределах полезной нагрузки ответа.И именно это я и сделаю.

Предлагаемые шаги:

• Отправить запрос на поиск через POST
• Сохранить определение запроса
• Создать URI для сохраненного запроса
• Выполнить поиск по запросу
• Вернуть ответ с кодом состояния 201 Created и заголовком Location, указывающим на URI сохраненного запроса, и добавить результат запроса в полезную нагрузку ответа

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

КакURI должен выглядеть так, как будто он не определен архитектурой REST.Вы можете сгенерировать UUID или сгенерировать хеш-значение на основе запроса.Последний подход имеет то преимущество, что множественные идентичные запросы не приводят к созданию дополнительных запросов, а к их повторному использованию.В таких случаях следует выполнить перенаправление на существующий ресурс запроса, чтобы сообщить клиенту, что его запрос уже существует, что также учитывает фактический URI ресурса запроса как побочный эффект.