Интерфейс поиска REST и идемпотентность GET
Чтобы придерживаться концепций REST, таких как безопасные операции, идемпотентность и т. Д., Как можно реализовать сложную операцию поиска, включающую несколько параметров?
Я видел реализацию Google, и это творческий подход. Какой вариант, кроме этого?
Требование идемпотента - это то, что сбивает меня с толку, поскольку операция определенно не будет возвращать одинаковые результаты по одним и тем же критериям, например, поиск клиентов по имени "Смит" не будет возвращать один и тот же набор каждый раз, потому что добавляется больше клиентов "Смит" все время. Мой инстинкт состоит в том, чтобы использовать GET для этого, но для истинной функции поиска результат не будет казаться идемпотентным, и его нужно будет пометить как не кэшируемый из-за его гибкого набора результатов.
3 ответа
Другими словами, основы идемпотентности в том, что операция 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 - такими вещами, как кэширование и согласование контента.
Большинство ресурсов не изменяются быстро, и полагаясь на определенные транзакции, используя неидемпотентные глаголы, предлагает более предсказуемый и согласованный интерфейс для клиентов. Когда метод должен быть идемпотентным, клиенты будут весьма удивлены, когда окажется, что это не так. Но, в конце концов, дело за приложением и задокументированным интерфейсом.
GET безопасен и идемпотентен при правильной реализации. Это означает:
- Это не вызовет видимых клиентом побочных эффектов на стороне сервера.
- Направленный на один и тот же URI, он приводит к тому, что одна и та же функция на стороне сервера выполняется каждый раз, независимо от того, сколько раз она была выпущена или когда
Что не сказано выше, так это то, что GET для одного и того же URI всегда возвращает одни и те же данные.
GET приводит к тому, что одна и та же функция на стороне сервера выполняется каждый раз, и обычно эта функция "возвращает представление запрошенного ресурса". Если этот ресурс изменился с момента последнего GET, клиент получит последние данные. Функция, которую выполняет сервер, является источником идемпотентности, а не данных, которые он использует в качестве входных данных (состояние запрашиваемого ресурса).
Если временная метка используется в URI для проверки того, что запрашиваемые данные сервера каждый раз одинаковы, это просто означает, что то, что уже идемпотентно (функция, реализующая GET), будет воздействовать на одни и те же данные, гарантируя тем самым тот же результат каждый раз.
Это было бы идемпотентом для того же набора данных. Вы можете достичь этого с помощью фильтра отметок времени.