Почему запрос PATCH не всегда идемпотентен?

Question

[AlexAK_466]

Я не могу понять в каких случаях PATCH будет индемпотентен а в каких нет. Знакомые программисты рассказывают одно, Chat GPT выдаёт совсем другую картину. Если такой вопрос попадётся на собеседовании, как на него правильно отвечать?

Answer 1

[Василий Банников]

Например у тебя в patch запросе может быть какой-нибудь jsonpatch в котором будет операция "добавить элемент в список".

И вот у тебя при многократном вызове будет добавляться много элементов.

Метод PATCH не является идемпотентным по RFC 9110 => такое поведение не будет считаться ошибочной реализацией протокола.

Никто не может запретить сделать подобное поведение в каком-нибудь GET или PUT, но так как они описаны в спецификации как идемпотентные, то такая реализация будет ошибочной и может привести к ряду неожиданных проблем, ведь клиенты всё ещё по-умолчанию будут считать их идемпотентными.

Comments

[Петр]

JSON Merge Patch (RFC 7386) является идемпотентным

[Василий Банников]

Петр, а вот https://jsonpatch.com/ - нет.

Да и patch вполне может принимать в себя и какой-нибудь xlst

Answer 2

[Everything_is_bad]

ну гуглиться же за раз https://developer.mozilla.org/ru/docs/Web/HTTP/Ref... скорее отсюда же и был взят для собеседования

Comments

[AlexAK_466]

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

[Василий Банников]

AlexAK_466, есть rfc 9110, пункт 9.2.2
https://httpwg.org/specs/rfc9110.html#rfc.section.9.2.2

Идемпотентными методами являются методы PUT, DELETE и все безопасные методы.

Все остальные - не идемпотентные (не обязаны быть идемпотениными), в том числе и PATCH.
Точка.

И никаких условий

[Everything_is_bad]

AlexAK_466,

но надо обьяснить условия для этого.

как раз по этой ссылке и объясняется

[сергей кузьмин]

HTTP protocol def:

GET, HEAD, PUT, DELETE, OPTIONS, and TRACE are examples of idempotent methods,
POST is generally not (creates a resource sans the ID).

PATCH is like PUT but designed for updating only specific parts of a resource, rather than replacing the whole resource

Why PATCH is generally considered non-idempotent:
Partial Modifications: PATCH is designed to apply partial modifications to a resource,
The effect of a PATCH request can depend on the current state of the resource and the order in which multiple PATCH requests are applied.
For example, if a PATCH request modifies an auto-incrementing counter, repeated requests would result in the counter continuing to increment, leading to different final states.

GET, HEAD, PUT, DELETE, OPTIONS, and TRACE are considered idempotent because multiple identical requests will have the same effect as a single request.
PUT is always idempotent as it replaces the entire resource, ensuring the final state is the same regardless of how many times the request is sent.
помогло надеюсь