Можно ли PUT запросом изменить только один атрибут ресурса

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

Знаете ли вы семантику методов HTTP и, что для тестировщика важнее, умеете ли проверить, как её реализовал конкретный сервер. Следом почти всегда спрашивают про разницу PUT и PATCH и про идемпотентность.

Как отвечать

По спецификации (RFC 9110) PUT заменяет состояние ресурса тем представлением, которое пришло в теле. Значит, клиент должен прислать ресурс целиком, даже если меняется одно поле. Для частичного изменения предназначен PATCH (RFC 5789).

Технически отправить PUT с одним полем можно, а результат зависит от реализации:

• остальные поля обнулились или сбросились в дефолт: поведение по стандарту, частичный PUT здесь опасен;
• сервер вернул 400 или 422: реализация требует полное представление и валидирует его;
• изменилось одно поле, остальные на месте: сервер фактически реализовал PUT как PATCH. Работает, но это отступление от семантики, и его стоит зафиксировать в баге или в документации API.

Проверяется это просто: GET до запроса, PUT с одним полем, снова GET и сравнение всех полей. Туда же проверка идемпотентности: повторный одинаковый PUT не должен менять результат. У PATCH идемпотентность не гарантирована и зависит от формата: JSON Merge Patch (application/merge-patch+json) заменяет поля, JSON Patch (application/json-patch+json) описывает операции, и операция add в конец массива при повторе добавит элемент ещё раз.

Упомяните, что PUT на несуществующий ресурс может его создать и вернуть 201, если API так устроен.

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

Утверждают как факт, что остальные поля «удалятся». Это верно для стандарта, но конкретный сервис ведёт себя по-своему, и задача QA как раз в том, чтобы это проверить.

Путают идемпотентность с безопасностью. PUT идемпотентен, но не безопасен: состояние он меняет.

Проверяют только код ответа 200. Реальную порчу данных видно лишь по следующему GET, а без него отчёт о тесте ничего не доказывает.