Что такое идемпотентность в методах HTTP?

Я прочитал HTTP документацию, но не могу понять, что такое идемпотентность. Может кто-нибудь помочь?

Ответ 1

Что такое идемпотентность в методах HTTP?

Идемпотентность является свойством методов HTTP.

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

Чтобы проиллюстрировать это, рассмотрим метод DELETE, который определяется как идемпотент. Теперь рассмотрим, как клиент выполняет запрос DELETE для удаления ресурса с сервера. Сервер обрабатывает запрос, ресурс удаляется, а сервер возвращает 204. Затем клиент повторяет тот же запрос DELETE и, поскольку ресурс уже удален, сервер возвращает 404.

Несмотря на различный код состояния, полученный клиентом, эффект, вызванный одним запросом DELETE, является тем же эффектом, что и несколько запросов DELETE к одному и тому же URI.

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

RFC 7231

Давайте взглянем на RFC 7231, документ определяет семантику и содержание протокола HTTP/1.1. См. цитаты ниже (основные моменты - мои).

Методы HTTP могут быть безопасными:

4.2.1. Safe Methods

Методы запроса считаются "безопасными", если их определенная семантика по существу доступна только для чтения; т.е. клиент не запрашивает и не ожидает какого-либо изменения состояния на исходном сервере в результате применения безопасного метода к целевому ресурсу. [...]

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

Из методов запроса, определенных в этой спецификации, методы GET, HEAD, OPTIONS и TRACE определены как безопасные. [...]

И/или идемпотент:

4.2.2. Idempotent Methods

Метод запроса считается "идемпотентным", если предполагаемый эффект на сервере нескольких идентичных запросов с помощью этого метода такой же, как эффект для одного такого запроса. Из методов запроса, определенных в этой спецификации, PUT, DELETE и безопасные методы запроса являются идемпотентными. [...]

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

Итак, методы HTTP классифицируются как следующие:

+---------+------+------------+
| Method  | Safe | Idempotent |
+---------+------+------------+
| CONNECT | no   | no         |
| DELETE  | no   | yes        |
| GET     | yes  | yes        |
| HEAD    | yes  | yes        |
| OPTIONS | yes  | yes        |
| POST    | no   | no         |
| PUT     | no   | yes        |
| TRACE   | yes  | yes        |
+---------+------+------------+

RFC 5789

RFC 5789 определяет метод PATCH, который не является ни безопасным, ни идемпотентным. Однако для предотвращения коллизий PATCH запросы могут быть отправлены таким образом, чтобы быть идемпотентными, как указано ниже:

Запрос PATCH может быть выдан таким образом, чтобы быть идемпотентным, что также помогает предотвратить нежелательные исходы от коллизий между двумя запросами PATCH на одном и том же ресурсе в аналогичном временном интервале. Столкновения из нескольких запросов PATCH могут быть более опасными, чем коллизии PUT, поскольку некоторые форматы исправлений должны работать с известной базовой точки, иначе они повредят ресурс. Клиенты, использующие этот тип приложения исправлений, ДОЛЖНЫ использовать условный запрос, так что запрос не будет выполнен, если ресурс был обновлен с момента последнего доступа клиента к ресурсу. Например, клиент может использовать сильный ETag в заголовке If-Match по запросу PATCH.

Ответ 2

По моему мнению, idempotency не имеет ничего общего с результатом (= Server Response), но с состоянием сервера после одного или нескольких вызовов.

Предположим, вы хотите удалить ресурс на сервере, позвонив

DELETE /resource/123

Вызов может возвратиться с HTTP-Response 200 OK и удаленным ресурсом в качестве полезной нагрузки в первую очередь. Во втором вызове ответ будет 204 NO_CONTENT поскольку ресурс уже был удален первым вызовом.

После каждого запроса состояние сервера одинаковое, поэтому идемпотентность выполняется. HTTP/1.1 ничего не говорит об ответе

Метод запроса считается "идемпотентным", если предполагаемый эффект на сервере с несколькими идентичными запросами с этим методом совпадает с эффектом для одного такого запроса

Ответ 3

| Патч | нет | нет | Я просто пытаюсь добавить этот метод в список.

Ответ 4

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

ПОСТ НЕ ИДЕМПТОТЕНТ. GET, PUT, DELETE, HEAD, OPTIONS и TRACE являются идемпотентными.

1> POST → Каждый раз, когда вы вызываете этот метод, он дает другой результат Why--> Рассмотрим сценарий, в котором вы создаете новые ресурсы. Каждый раз, когда вы вызываете этот метод, он будет приводить к созданию новых ресурсов. Каждый раз вы будете получать разные результаты. и, следовательно, POST (в простом слове "Вставить") не идемпотентный метод.

2> Другой даст вам тот же результат

Ответ 5

TL;DR

Idempotenc: GET, PUT: ПОЧЕМУ?

GET При запуске рекурсивного точного /resource/123 он даст тот же результат
PUT Если уволен рекурсивно точный /user/123 он даст тот же результат

НЕ ИДЕМПОТЕНЦИЯ: УДАЛИТЬ, ПОЧТА: ПОЧЕМУ?

DELETE Если выпустили рекурсивно точный /user/123 это даст другой результат второй раз (404 или NOT_FOUND)
POST Если у вас есть рекурсивно точный /user/(id is assigned by server) он будет давать разные результаты каждый раз

Confusions: DELETE является Idempotenc по http docs, но его поведение - не-идемпотентность

Вывод:

Запрос - Idempotenc

если запрос дает тот же результат

для точного же URL-адреса

else non Idempotenc

Ответ 6

Методы Idenpotent (GET, OPTIONS) ничего не меняют на сервере (кроме возможности добавления записей в журнал). Методы non-idempotent (PUT, POST, DELETE) изменяют данные, которые используются для заполнения контента на веб-страницах или изменения эффекта в другом месте (например, перемещение крана, перенос средств, отправка электронной почты).