Что будет если отправить PUT с изменением одной строчки?

Развёрнутый ответ о поведении PUT-запроса

Основной принцип HTTP PUT

PUT — это идемпотентный метод HTTP, который предполагает полную замену ресурса предоставленным представлением. Когда вы отправляете PUT-запрос для изменения одной строки, вы фактически не "изменяете строку", а полностью перезаписываете весь ресурс.

Что происходит технически

PUT /api/users/123 HTTP/1.1
Content-Type: application/json

{
    "id": 123,
    "name": "Иван Иванов",
    "email": "new@example.com",  // Изменили только email
    "role": "admin"
}

В этом примере, даже если вы изменили только поле email, весь объект пользователя будет заменён. Сервер не делает частичных обновлений при стандартном использовании PUT — он интерпретирует тело запроса как новое полное состояние ресурса.

Ключевые последствия и риски

• Потеря данных: Если клиент отправил устаревшее или неполное представление ресурса, другие поля могут быть перезаписаны значениями по умолчанию или null
• Конкурентность: При одновременных обновлениях последний PUT "победит", что может привести к потере изменений
• Валидация: Сервер должен проверять всю новую версию ресурса, а не только изменённые поля
• Производительность: Передача всего ресурса может быть избыточной при изменении одного поля

Лучшие практики для QA Engineer

При тестировании PUT-эндпоинтов необходимо проверять:

1. Идемпотентность: Повторный запрос с теми же данными даёт тот же результат
2. Валидацию полей: Все обязательные поля присутствуют и валидны
3. Конкурентный доступ: Использование заголовков If-Match или If-Unmodified-Since для оптимистичной блокировки
4. Частичные обновления: Рекомендовать разработчикам использовать PATCH для точечных изменений

Пример проблемного сценария для тестирования

// Проблема: клиент получает ресурс, изменяет одно поле и отправляет обратно
// Original: {id: 1, name: "Иван", email: "old@test.com", role: "user"}
// Client modifies only email: "new@test.com"

// НЕПРАВИЛЬНО - отправить только изменённое поле:
PUT /api/users/1
{"email": "new@test.com"} // ПОТЕРЯ ДАННЫХ! name и role станут undefined

// ПРАВИЛЬНО - отправить полный ресурс:
PUT /api/users/1
{"id": 1, "name": "Иван", "email": "new@test.com", "role": "user"}

// ЛУЧШЕ - использовать PATCH для частичного обновления:
PATCH /api/users/1
{"email": "new@test.com"}

Рекомендации по тест-кейсам

• Негативное тестирование: Отправка PUT с неполным телом запроса
• Тестирование конкурентности: Два одновременных PUT к одному ресурсу
• Валидация граничных значений: Максимально допустимый размер тела запроса
• Тестирование отката: Проверка, что ресурс возвращается в предыдущее состояние при ошибке
• Совместимость: Проверка обработки устаревших клиентов, отправляющих частичные данные

Вывод для QA Specialist

Понимание семантики HTTP методов критически важно для эффективного тестирования REST API. При обнаружении в коде использования PUT для частичных обновлений необходимо:

1. Завести баг-репорт о потенциальной потере данных
2. Предложить использование PATCH с форматом JSON Patch или JSON Merge Patch
3. Добавить в тестовую стратегию сценарии проверки идемпотентности и конкурентного доступа
4. Рекомендовать реализацию оптимистичной блокировки через ETag

Правильное понимание этих нюансов отличает senior QA engineer от junior — вы должны не только находить баги, но и понимать их архитектурные корни и предлагать оптимальные решения.