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

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

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

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

9
rest web-services

3 ответов

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

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

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

GET /current-time

GET /current-weather/90210

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

контраст:

GET /next-counter

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

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

А как быть, скажем:

GET /logs

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

о:

GET /random-number

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

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

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

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

23

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

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

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

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

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

9

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

2