PUT
идемпотент, PATCH
нет. Тот факт, что PUT
является идемпотентом , означает, что компоненты общего назначения могут повторять один запрос столько раз, сколько необходимо для получения ответа.
PATCH
как и POST
, не обещает идемпотентную семантику; поэтому компоненты общего назначения более жестко ограничены с точки зрения того, какие действия они могут выполнять самостоятельно.
Если все поля обновлены, в этом случае обе операции являются идемпотентными, верно?
Компонент общего назначения не будет понимать, обновлены ли все поля. Высокий уровень heuristi c заключается в следующем: компоненты общего назначения понимают семантику заголовков HTTP, но не обязательно семантику тел сообщений.
И, в этом случае, почему PATCH полного ресурса, не идемпотентного?
Реализация PATCH действительно может быть идемпотентной. Но это не обязательно - семантика запросов PATCH не обещает идемпотентную обработку, и поэтому компоненты общего назначения не должны предполагать.
Аналогия, которая может помочь: мы предпочитаем использовать GET для запросов, потому что GET безопасен . Однако иногда мешают другие вещи (например, фактические ограничения длины URI), и мы вынуждены использовать POST. Нет абсолютно никакой причины, по которой мы не можем создать обработчик POST, который эффективно предназначен только для чтения.
Но у нас нет какого-либо механизма, который позволяет нам сообщать клиенту общего назначения о том, что происходит именно это использование POST быть безопасным.
GET определен как безопасный, и, следовательно, каждый ресурс в мире должен безопасно с ним обращаться. POST не определен как безопасный; только некоторые ресурсы в мире обрабатывают POST безопасно. И поэтому компоненты общего назначения не могут предположить , что какой-либо конкретный ресурс безопасно обрабатывает запрос POST.
То же самое относится и к идемпотентной семантике, и PUT против POST / PATCH.