HTPP PATCH метод считается не идемпотентным и применяет частичные модификации к ресурсу,
в отличие от PUT, который идемпотентен и применяет замену ресурса.
(как MDN состояния):
Метод запроса HTTP PATCH применяет частичные изменения к ресурсу.
Метод HTTP PUT позволяет только полную замену документа.В отличие от PUT, PATCH не идемпотентен, то есть последовательные идентичные запросы на исправление могут иметь разные эффекты.
Но возможно реализовать PATCH идемпотентным способом (MDN):
Однако можно выдавать запросы PATCH таким образом, чтобы они были идемпотентными.
Пример идемпотентной реализации патча:
path: /contact/:id
method: patch
body {
name: 'John'
}
независимо от того,Сколько раз будет выполнен этот запрос - ресурс останется в том же состоянии, что и после первого запроса.
, поскольку идемпотентный запрос оптимизируется ( ссылка ):
Клиенты могут автоматически отменить запрос GET, если его обработка занимает слишком много времени, и повторить его, поскольку они предполагают, что он имеет тот же эффект (поскольку GET является идемпотентом).Тем не менее, они не будут делать то же самое для запросов POST, потому что первый, возможно, уже изменил некоторое состояние на стороне сервера.
Как я понимаю, эта оптимизация может быть применена только к http-методам, которыесчитаются идемпотентными по стандарту HTTP.
Поэтому идемпотентный запрос PATCH, который я написал выше, не будет оптимизирован.(насколько я понимаю, стандарт HTTP гласит, что патч не идемпотентен, но не запрещает его реализацию как идемпотента).
Поскольку PUT считается идемпотентом по стандарту HTTP.Не предпочтительнее ли использовать запрос PATCH / contact /: id в качестве PUT (для получения упомянутой выше оптимизации)?
ОБНОВЛЕНИЕ 1
Я могу изменить запрос на PUT и реализовать его на сервере таким образом, чтобы он обновлял только те свойства, которые были отправлены в полезной нагрузке запроса, и игнорировал свойства, которые не были отправлены.таким образом я делаю запрос PUT, который модифицирует части ресурса идемпотентным способом, который будет оптимизирован, и я не заменяю весь ресурс.событие, если ресурс очень большой, а изменение, которое я хочу сделать, очень мало, если оно реализовано идемпотентным образом, не лучше ли использовать PUT каждый раз?
, что приводит меня к названию: idempotentЧастичные модификации ресурса лучше реализовывать как PUT вместо PATCH?
ОБНОВЛЕНИЕ 2:
Как указано в этом вопросе ответы: 1 , 2
Причина частичных модификаций идемпотента HTTP лучше не реализуется, поскольку PUT: Он не поддается архитектуре REST
некоторые из недостатков, которые идут с этим:
другие программисты не поймут PUT частичного обновления, и следует написать дополнительную документацию относительно этой конечной точки.
Не удастся получить точный ресурс, который был отправлен в предыдущем «PUT частичного обновления».
, так как REST сфокусированна лЧто касается эволюции нашего API, то его соблюдение может сэкономить нам время в будущем.
и, возможно, существует гораздо больше недостатков, связанных с несоблюдением архитектурного стиля REST ...
но если мы посмотрим на это с точки зрения производительности, если запрос идемпотентен, то обновление Partial PUT лучше (поскольку оно получает оптимизацию, упомянутую выше).
я был бы радуслышать еще несколько причин, которые приходят на ум :).
Спасибо