Можно ли обновлять данные методом POST и является ли это архитектурно верным решением
Что проверяют
Отличаете ли вы «технически возможно» от «семантически верно» и понимаете ли, что метод меняет поведение инфраструктуры вокруг сервиса. Для тестировщика важнее второе: какие проверки вы придумаете, если разработчик обновляет данные через POST. Следом спрашивают про идемпотентность и повторную отправку.
Как отвечать
Технически да: HTTP не запрещает менять состояние любым методом, тело POST сервер разберёт так же. Дальше про семантику RFC 9110:
- POST: небезопасный и неидемпотентный, тело обрабатывается по правилам конкретного ресурса. К нему сводят всё, что не укладывается в CRUD;
- PUT: замена ресурса целиком по известному адресу, идемпотентен, то есть пять одинаковых запросов дают то же состояние, что и один;
- PATCH: частичное изменение, идемпотентность не гарантируется, операция вида «увеличить счётчик на единицу» тому пример.
Практическое значение не в чистоте REST, а в поведении окружения. Клиенты, прокси и балансировщики умеют безопасно повторять идемпотентные запросы при таймауте, а POST повторять нельзя, иначе появится второй заказ. Ответ на POST по умолчанию некэшируем.
Зрелый ответ: POST для изменения уместен, когда операция это действие, а не замена состояния (/orders/42/cancel), и когда так устроен сам протокол, например GraphQL ходит одним POST. Неидемпотентность лечится ключом Idempotency-Key в заголовке, как у платёжных шлюзов.
QA-часть, ради которой вопрос и задан. Проверяйте повторную отправку одного запроса, поведение при таймауте и ретрае, коды ответа (200 и 204 против 201 с Location), частичное тело (не затираются ли незаданные поля в null) и гонку двух одновременных обновлений.
Где спотыкаются
Отвечают «нельзя, это нарушает REST» и на этом заканчивают. Интервьюер ждал разбора последствий, а не запрета.
Считают, что PUT обязан быть быстрее или безопаснее. Разницы в транспорте нет, вся разница в договорённости о поведении.
Определяют идемпотентность как «ответ всегда одинаковый». Одинаковым должно быть состояние сервера, а ответ может отличаться: 201 на первый запрос и 200 на повтор.