Что произойдёт при PUT-запросе с атрибутами сущности, которой ещё нет в базе данных?

Что происходит при PUT для отсутствующей сущности?

• HTTP-метод PUT используется для полной замены ресурса по указанному URI
• Если ресурс с таким URI не найден, стандарт допускает его создание сервером
• Согласно RFC 7231, при отсутствии ресурса на сервере PUT должен создать его
• Фактическое поведение определяется реализацией API, однако многие сервисы придерживаются этого правила
• Если API не разрешает создание ресурса через PUT, сервер может вернуть ошибку 404 или 405
• Для создания ресурсов часто выбирают POST, но PUT также подходит для идемпотентного создания или замены
• Вывод: при отправке через PUT атрибутов отсутствующей сущности сервер обычно создаёт новую запись с переданными значениями

Такой ответ демонстрирует понимание HTTP-методов, соответствующих стандартов и практических принципов проектирования API — именно это важно на техническом собеседовании.

Развёрнутый ответ

Краткий ответ

По спецификации REST при выполнении HTTP-метода PUT, если указанная сущность ещё отсутствует в базе данных, сервер должен создать её, используя переданные атрибуты. То есть PUT применяется для полной замены ресурса по конкретному URI, а при отсутствии такого ресурса — для его создания. В отличие от POST, который обычно создаёт новый ресурс с назначаемым сервером URI, PUT является идемпотентным и используется как для создания, так и для обновления.

Что важно учитывать

• Идемпотентность: Повторная отправка одинаковых PUT-запросов приводит к тому же результату: ресурс создаётся или обновляется, сохраняя одно и то же состояние.
• Создание отсутствующего ресурса: Если ресурс с указанным идентификатором не найден, сервер формирует его из переданных данных — например, в REST API, работающем с PostgreSQL или MongoDB.
• Отличие от POST: POST создаёт новый ресурс и, как правило, не является идемпотентным, тогда как PUT адресно создаёт или заменяет ресурс по заданному URI и сохраняет идемпотентность.
• Конкретный результат определяется сервером и контрактом API: отдельные сервисы могут запрещать создание через PUT, хотя такой подход не соответствует стандартной семантике REST.

Пример из практики

Представим API управления пользователями. Запрос PUT /users/123 с данными пользователя создаст запись с ID=123, если такого пользователя ещё нет, либо обновит существующую запись. При реализации сервера в соответствии с принципами REST клиенту не требуется заранее проверять наличие ресурса. Это упрощает клиентскую логику и позволяет сократить число запросов.