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

Question

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

Я видел реализацию Google, и это креативно,Что может быть, кроме этого?

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

Answer 1

Другими словами, основы идемпотентности в том, что операция 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 - такими вещами, как кеширование и согласование контента.

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

Answer 2

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

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

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

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

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

Answer 3

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