Ответ 1
Что такое идемпотентность в методах HTTP?
Идемпотентность является свойством методов HTTP.
Метод запроса считается идемпотентным, если предполагаемое воздействие на сервер нескольких идентичных запросов с помощью этого метода такое же, как и эффект для одного такого запроса. И стоит упомянуть, что идемпотентность связана с влиянием, оказываемым на состояние ресурса на сервере, а не с кодом состояния ответа, полученным клиентом.
Чтобы проиллюстрировать это, рассмотрим метод DELETE, который определяется как идемпотент. Теперь рассмотрим, как клиент выполняет запрос DELETE для удаления ресурса с сервера. Сервер обрабатывает запрос, ресурс удаляется, а сервер возвращает 204. Затем клиент повторяет тот же запрос DELETE и, поскольку ресурс уже удален, сервер возвращает 404.
Несмотря на различный код состояния, полученный клиентом, эффект, вызванный одним запросом DELETE, является тем же эффектом, что и несколько запросов DELETE к одному и тому же URI.
Наконец, запросы с идемпотентными методами могут повторяться автоматически, если сбой связи происходит до того, как клиент сможет прочитать ответ сервера. Клиент знает, что повторение запроса будет иметь тот же предполагаемый эффект, даже если исходный запрос был выполнен успешно, хотя ответ может отличаться.
RFC 7231
Давайте взглянем на RFC 7231, документ определяет семантику и содержание протокола HTTP/1.1. См. цитаты ниже (основные моменты - мои).
Методы HTTP могут быть безопасными:
Методы запроса считаются "безопасными", если их определенная семантика по существу доступна только для чтения; т.е. клиент не запрашивает и не ожидает какого-либо изменения состояния на исходном сервере в результате применения безопасного метода к целевому ресурсу. [...]
Это определение безопасных методов не препятствует тому, чтобы реализация включала в себя поведение, которое потенциально опасно, не является полностью доступным только для чтения или вызывает побочные эффекты при вызове безопасного метода. Однако важно то, что клиент не запрашивал такого дополнительного поведения и не может нести за него ответственность. [...]
Из методов запроса, определенных в этой спецификации, методы
GET,HEAD,OPTIONSиTRACEопределены как безопасные. [...]
И/или идемпотент:
Метод запроса считается "идемпотентным", если предполагаемый эффект на сервере нескольких идентичных запросов с помощью этого метода такой же, как эффект для одного такого запроса. Из методов запроса, определенных в этой спецификации,
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.