Что возвращается при отправке PUT на несуществующий ресурс согласно контракту

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

Различаете ли вы «как в спецификации HTTP» и «как записано в контракте конкретного API», и умеете ли формулировать ожидаемый результат до прогона. Для тестировщика это вопрос не про код ответа, а про источник истины.

Как отвечать

По семантике HTTP PUT это «положи представление ресурса по этому URI». Если ресурса не было и сервер разрешает создание по адресу, который выбирает клиент, корректный ответ 201 с заголовком Location. Если ресурс существовал и обновился, ответ 200 с телом или 204 без тела.

Но 404 тоже законен, и именно он чаще встречается: когда идентификаторы выдаёт сервер, создавать сущность по произвольному PUT нельзя. Рядом живут 409 при конфликте состояния и 405, если метод для пути не поддерживается.

Поэтому правильный ответ на собеседовании начинается с контракта: смотрю описание операции в спецификации и сверяю фактический ответ с ним, а расхождение оформляю дефектом. Что проверяю по такому кейсу:

• статус, тело ошибки и Location при создании;
• побочный эффект: появился ресурс или нет, подтверждаю запросом GET;
• идемпотентность: повторный такой же PUT не создаёт дубль;
• неполное тело, ведь PUT заменяет ресурс целиком;
• чужой и заведомо невалидный идентификатор.

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

Называют единственно верным 404 и спорят. Оба поведения допустимы, вопрос только в том, что обещает контракт, и уверенный однозначный ответ здесь читается как пробел.

Второе: путают с PATCH и POST. PUT идемпотентен и заменяет целиком, PATCH меняет частично, POST не идемпотентен и повторный вызов плодит сущности.

Третье: проверяют только код ответа. Сервис может ответить 404 и при этом создать запись или частично обновить связанные данные, поэтому состояние после запроса нужно смотреть отдельно.