Какие виды запросов отвечают за каждый параметр CRUD

Вопрос

Какие виды запросов отвечают за каждый параметр CRUD

Профессия

Frontend Developer

Что хочет услышать интервьюер

Интервьюер хочет убедиться, что кандидат понимает соответствие HTTP-методов операциям CRUD и может объяснить разницу между PUT и PATCH.

Ключевые тезисы

• CRUD — это аббревиатура для Create, Read, Update, Delete, которые соответствуют основным операциям с данными.
• Create (создание) — POST запрос, используется для добавления новых данных на сервер.
• Read (чтение) — GET запрос, позволяет получать данные с сервера без их изменения.
• Update (обновление) — PUT или PATCH запросы. PUT заменяет весь ресурс, PATCH — только его часть.
• Delete (удаление) — DELETE запрос, удаляет указанный ресурс на сервере.

Подробный ответ

CRUD — это базовая модель операций с данными, где каждая буква соответствует определенному HTTP-методу. Create (создание) реализуется через POST, который отправляет данные на сервер для создания нового ресурса. Read (чтение) использует GET для получения данных без их изменения. Update (обновление) может выполняться через PUT (полная замена ресурса) или PATCH (частичное обновление). Delete (удаление) использует метод DELETE для удаления указанного ресурса.

Важно понимать разницу между PUT и PATCH: PUT требует отправки всего ресурса даже при изменении одного поля, тогда как PATCH отправляет только изменяемые поля. Это влияет на производительность и безопасность.

Идемпотентность — ключевое свойство некоторых методов: GET, PUT, DELETE идемпотентны (повторный запрос не изменяет результат), а POST — нет. Это критично для обработки ошибок и повторов запросов.

Для сложных операций, выходящих за рамки CRUD, часто используют POST, так как он не ограничен стандартными семантиками, либо создают отдельные RESTful-эндпоинты с четкой документацией.

Практические примеры

Пример 1

Пример создания пользователя: POST /users с телом { 'name': 'John', 'email': 'john@example.com' }

Пример 2

Пример частичного обновления: PATCH /users/123 с телом { 'email': 'new@example.com' }

Пример 3

Пример идемпотентного DELETE: повторный DELETE /users/123 вернет 404, но состояние системы не изменится

Частые ошибки

• Использование GET для операций, изменяющих данные (нарушение идемпотентности)
• Отправка всех полей в PATCH вместо только изменяемых
• Неверная интерпретация кодов ответа (например, 200 вместо 204 для успешного DELETE)

Связанные темы

• RESTful API design principles
• HTTP status codes (200, 201, 204, 400, 404, etc.)
• Idempotency keys for non-idempotent operations
• HATEOAS как расширение CRUD-модели

Follow-up вопросы

В чем разница между PUT и PATCH?

Уровень: intermediate

PUT полностью заменяет ресурс на сервере новыми данными, тогда как PATCH применяет частичные изменения к ресурсу. PUT требует отправки всего объекта, даже если меняется одно поле, а PATCH — только изменяемых полей.

Можно ли использовать GET для передачи чувствительных данных? Почему?

Уровень: basic

Нет, GET-запросы кешируются, сохраняются в истории браузера и видны в URL, что делает их небезопасными для передачи паролей или токенов. Для таких данных следует использовать POST с HTTPS.

Какой HTTP-метод следует использовать для сложных операций, не вписывающихся в CRUD?

Уровень: advanced

Для нестандартных операций (например, запуск процесса) можно использовать POST, так как он универсален. В REST API иногда применяют расширения вроде POST /resource/action или отдельные эндпоинты.

Что такое idempotency (идемпотентность) методов и какие методы CRUD идемпотентны?

Уровень: intermediate

Идемпотентность означает, что повторный вызов метода даст тот же результат. GET, PUT, DELETE — идемпотентны (повторение не изменит состояние системы). POST не идемпотентен — каждый вызов создает новый ресурс.

Как обрабатывать ошибки в CRUD-операциях? Какие HTTP-коды использовать?

Уровень: intermediate

400 — неверный запрос, 401/403 — проблемы аутентификации/авторизации, 404 — ресурс не найден, 409 — конфликт (например, при дублировании данных). Для успешных операций: 200 (OK), 201 (Created для POST), 204 (No Content для DELETE).