Интерфейс поиска REST и идемпотентность GET

Чтобы придерживаться концепций REST, таких как безопасные операции, идемпотентность и т.д., как можно реализовать сложную операцию поиска с несколькими параметрами?

Я видел реализацию Google, и это творчески. Что такое вариант, кроме этого?

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

Ответ 1

Другими словами, основы idempotency заключаются в том, что операция GET не влияет на результаты операции. То есть, GET можно безопасно повторять без каких-либо побочных эффектов.

Однако запрос идемпотента не имеет ничего общего с представлением ресурса.

Два надуманных примера:

GET /current-time

GET /current-weather/90210

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

Контраст:

GET /next-counter

Это, очевидно, я надеюсь, а не идемпотентный запрос. Сам запрос изменяет ресурс.

Кроме того, нет ничего, что говорит о том, что идемпотентная операция не имеет побочных эффектов. Очевидно, что много системных журнальных обращений и запросов, включая GET. Поэтому, когда вы выполняете GET/resource, журналы будут меняться в результате GET. Такой побочный эффект не делает GET не идемпотентным. Основная предпосылка - это влияние на сам ресурс.

Но как насчет, скажем:

GET /logs

Если журналы регистрируют каждый запрос, а GET возвращает журналы в их текущем состоянии, означает ли это, что GET в этом случае не является идемпотентным? Ага! Это действительно имеет значение? Неа. Не для этого края. Просто характер игры.

Как насчет:

GET /random-number

Если вы используете генератор псевдослучайных чисел, большинство из них питаются сами собой. Начиная с семени и подавая свои результаты обратно в себя, чтобы получить следующий номер. Таким образом, использование GET здесь может быть не идемпотентным. Но так ли? Откуда вы знаете, как генерируется случайное число. Это может быть источник белого шума. И почему вас это волнует? Если ресурс - это просто случайное число, вы действительно не знаете, изменилась ли операция или нет.

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

Ресурсы меняются, это простой факт жизни. Представление ресурса не обязательно должно быть универсальным или согласованным между запросами или согласованным между пользователями. Буквально представление ресурса - это то, что дает GET, и это зависит от приложения, используя, кто знает, какие критерии определяют это представление для каждого запроса. Идемпотентные запросы очень приятные, потому что они хорошо работают с остальной моделью REST - такими, как кэширование и согласование контента.

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

Ответ 2

GET безопасен и идемпотент при правильной реализации. Это означает:

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

Что не сказано выше, так это то, что GET в тот же URI всегда возвращает одни и те же данные.

GET запускает одну и ту же функцию на стороне сервера каждый раз, и эта функция, как правило, "возвращает представление запрошенного ресурса". Если этот ресурс изменился с момента последнего GET, клиент получит последние данные. Функция , которую выполняет сервер, является источником идемпотентности, а не данными, которые она использует в качестве входных данных (состояние запрашиваемого ресурса).

Если временная метка используется в URI, чтобы удостовериться, что запрашиваемые данные сервера одинаковы каждый раз, это означает, что что-то, что уже идемпотент (функция, реализующая GET), будет действовать на одни и те же данные, тем самым гарантируя один и тот же результат каждый раз.

Ответ 3

Это было бы идемпотентным для одного и того же набора данных. Вы можете добиться этого с помощью фильтра метки времени.