В чем разница между HTTP методами PATCH и PUT?

Что проверяют

Понимаете ли вы семантику методов и знаете ли про идемпотентность. Вопрос кажется простым, но правильный ответ включает то, чего в документации API обычно не пишут.

Как отвечать

PUT заменяет ресурс целиком: клиент присылает полное представление, и сервер приводит ресурс к нему. Поле, которого нет в теле запроса, по смыслу должно обнулиться. Если ресурса не было, PUT может его создать по указанному адресу.

PATCH меняет ресурс частично: в теле только то, что нужно изменить, остальное сервер не трогает.

Дальше главное, ради чего вопрос и задают:

• PUT идемпотентен: повторите один и тот же запрос десять раз, состояние будет тем же, что после первого. Это позволяет клиенту безопасно повторять запрос при обрыве связи;
• PATCH идемпотентным быть не обязан: {"op": "increment", "field": "views"} при повторе даст другой результат. Он идемпотентен только если вы сами описали изменения как присвоение значений;
• формат тела: у PUT это обычное представление ресурса, у PATCH вариантов несколько. Чаще всего используют частичный JSON-объект, но есть и стандарты: JSON Merge Patch (RFC 7396), где null означает удаление поля, и JSON Patch (RFC 6902) со списком операций;
• коды ответов: 200 с телом, 204 без тела, 201 если ресурс создан.

Практический совет: для «поменять один статус» берут PATCH, для «сохранить форму целиком» удобнее PUT, и тогда клиент обязан присылать все поля, включая незаполненные.

Где спотыкаются

Делают PUT частичным обновлением. Это самая частая ошибка в самодельных API: метод по названию один, поведение другое, и клиент теряет данные, когда сервер всё-таки решит обнулить непереданные поля.

Не могут объяснить идемпотентность и путают её с безопасностью метода (GET безопасен, PUT нет).

Забывают, что PATCH с null в JSON Merge Patch удаляет поле, а не записывает пустое значение.