Разница между PUT и POST
Чем PUT отличается от POST, что означает идемпотентность и как вести себя при повторе запроса.
Создать заметку через POST или PUT? Ответ зависит от того, известен ли её адрес и что означает операция в вашем API. Для добавления записи в коллекцию обычно подходит POST. Если клиент задаёт состояние ресурса по известному адресу — PUT. Разберём примеры и то, что произойдёт при повторной отправке.
Создание через коллекцию
POST /api/notes
Content-Type: application/json
{"title":"Первая заметка"}Сервер обрабатывает переданное представление согласно смыслу ресурса. При создании нового объекта уместен ответ 201 и Location с его адресом. POST не ограничен только созданием: он используется и для других операций обработки. Поэтому правило «POST всегда добавляет строку» слишком узкое.
Известный адрес
PUT /api/notes/42
Content-Type: application/json
{"title":"Исправленная заметка"}PUT задаёт желаемое состояние целевого ресурса. Это не требует физического удаления и повторной вставки записи в базе. Важен результат и контракт представления. Для частичного изменения часто предусмотрен PATCH; формат такого изменения нужно согласовать отдельно.
Что означает идемпотентность
Повтор одинакового PUT должен иметь тот же предполагаемый эффект на целевой ресурс, что и один запрос. При этом журналы и другие сопутствующие действия могут отличаться. POST такого свойства по определению не обещает. Повтор после сетевого сбоя без дополнительной защиты может создать дубликат.
Проверяйте статусы, права и конфликты независимо от выбранного метода. Для защиты от перезаписи чужого изменения полезны версии или условные запросы. Для операций с повтором POST можно предусмотреть ключ идемпотентности, но это свойство вашего API, которое необходимо реализовать и проверить.
Повторите запрос, обратитесь к отсутствующему объекту и отправьте устаревшую версию. Проверьте реальные ответы сервера: названия PUT и POST сами по себе не обеспечивают нужное поведение. Оно должно быть определено в API и подтверждаться этими случаями.