CRUD

CRUD операции в REST API: Полное руководство

📚 27 вопросовПройти тест →
Лекция

CRUD операции в REST API: Полное руководство

CRUD

CRUD операции в REST API: Полное руководство

Введение: порядок на складе 📦

CRUD — это как работа склада: что‑то приняли (Create), нашли на полке (Read), обновили этикетку (Update), списали (Delete).
Если CRUD не упорядочен, API превращается в хаос: запросы непредсказуемы, данные ломаются, ошибки неясны.
💡 Совет: начинайте проектирование API с CRUD‑правил и названий ресурсов.
✅ Вывод: CRUD — это базовый «порядок» для всех REST API.

Проблема → решение

Проблема: команды путают методы, статусы и адреса, из‑за чего API сложно использовать и тестировать.
Решение: жёстко связать операции CRUD с HTTP‑методами, статусами и понятной структурой URL.
✅ Вывод: единые правила CRUD делают API стабильным и предсказуемым.

Чем помогает и как работает

CRUD помогает:
  • описывать API простыми, понятными действиями;
  • уменьшать ошибки при разработке и интеграции;
  • задавать единые правила ответов и статусов.
Как это работает:
  1. Выделяем ресурс (например, users).
  2. Определяем коллекцию (/users) и конкретный объект (/users/42).
  3. Назначаем методы: POST = create, GET = read, PUT/PATCH = update, DELETE = delete.
  4. Возвращаем правильные статусы (201, 200, 204, 404).
  5. Клиент понимает API без лишних объяснений.
✅ Вывод: CRUD — это общий язык между клиентом и сервером.

Ключевые термины (простыми словами)

  • Resource (ресурс) — сущность: пользователь, заказ, продукт.
  • Collection (коллекция) — список ресурсов (/users).
  • CRUD — базовые операции: создать, прочитать, обновить, удалить.
  • Idempotent (идемпотентный) — повтор не меняет результат.
  • Partial update (частичное обновление) — изменить только часть данных.

Самое важное (must‑know)

  • POST создаёт ресурс в коллекции и возвращает 201 + Location.
  • GET читает ресурс и не изменяет данные.
  • PUT заменяет ресурс целиком, PATCH — частично.
  • DELETE удаляет ресурс и обычно возвращает 204.
  • PUT и DELETE идемпотентны, POST — нет.
  • URL — это ресурсы, а не действия (/users/42, не /getUser).

1. Create (POST) — создание ресурса

Назначение: создать новый объект в коллекции.
Простыми словами: отправляем данные и получаем новый элемент.
Аналогия: оформить новый заказ в магазине.
Пример:
POST /usersContent-Type: application/json { "name": "Anna", "email": "anna@mail.com" } HTTP/1.1 201 CreatedLocation: /users/42
🔎 Как это происходит на практике:
  1. Клиент отправляет POST в коллекцию /users.
  2. Сервер валидирует данные и создаёт запись.
  3. Возвращает 201 и ссылку на новый ресурс.
Характеристики:
  • ✅ создаёт новый ресурс;
  • ✅ возвращает 201 и Location;
  • ❌ не идемпотентен.
Когда использовать: когда нужен новый объект.
✅ Вывод: POST — стандарт для создания.

2. Read (GET) — чтение данных

Назначение: получить ресурс или список.
Простыми словами: читаем данные без изменений.
Аналогия: посмотреть карточку товара.
Пример:
GET /users/42 HTTP/1.1 200 OK{ "id": 42, "name": "Anna" }
🔎 Как это происходит на практике:
  1. Клиент вызывает GET по URL ресурса.
  2. Сервер ищет данные.
  3. Возвращает 200 или 404.
Характеристики:
  • ✅ безопасный (safe);
  • ✅ идемпотентный;
  • ✅ подходит для кэширования.
Когда использовать: чтение данных и списков.
✅ Вывод: GET — только для чтения.

3. Update (PUT/PATCH) — обновление ресурса

Назначение: изменить существующий объект.
Простыми словами: обновляем данные у уже созданного элемента.
Аналогия: заменить адрес доставки в заказе.
Пример (PUT — полностью):
PUT /users/42{ "name": "Anna", "email": "new@mail.com" }
Пример (PATCH — частично):
PATCH /users/42{ "email": "new@mail.com" }
🔎 Как это происходит на практике:
  1. Клиент отправляет изменения на /users/42.
  2. Сервер валидирует и обновляет запись.
  3. Возвращает 200 или 204.
Характеристики:
  • ✅ PUT идемпотентен;
  • ✅ PATCH удобен для частичных изменений;
  • ✅ применяется к конкретному ресурсу.
Когда использовать: изменение существующих данных.
✅ Вывод: PUT = полностью, PATCH = частично.

4. Delete (DELETE) — удаление ресурса

Назначение: удалить объект.
Простыми словами: убираем элемент из системы.
Аналогия: списать товар со склада.
Пример:
DELETE /users/42 HTTP/1.1 204 No Content
🔎 Как это происходит на практике:
  1. Клиент вызывает DELETE по URL ресурса.
  2. Сервер удаляет запись или помечает как удалённую.
  3. Возвращает 204 или 404.
Характеристики:
  • ✅ идемпотентен;
  • ✅ обычно без тела ответа;
  • ✅ требует аккуратного контроля прав.
Когда использовать: удаление конкретного ресурса.
✅ Вывод: DELETE — аккуратное удаление.

5. Ресурс и коллекция — правильные URL

Назначение: разделить список и конкретный объект.
Простыми словами: есть список «все пользователи» и один «пользователь 42».
Аналогия: каталог товаров и карточка товара.
Пример:
Коллекция: /usersРесурс:    /users/42
🔎 Как это происходит на практике:
  1. Коллекция отвечает за список и создание.
  2. Ресурс отвечает за чтение, обновление, удаление.
  3. Методы привязаны к одному URL.
Характеристики:
  • ✅ адреса без глаголов;
  • ✅ предсказуемая навигация;
  • ✅ легко документировать.
Когда использовать: всегда при проектировании REST API.
✅ Вывод: URL — это существительные, не действия.

Сравнение: POST vs PUT vs PATCH

МетодКогдаИдемпотентен
POSTсоздать новый ресурс❌ нет
PUTполностью заменить ресурс✅ да
PATCHчастично обновить✅ зависит от дизайна

Сравнение: 200 vs 201 vs 204

КодКогда
200вернули данные
201создан новый ресурс
204успешно, но без тела

Типичные ошибки

Ошибка 1: POST для обновления

❌ Неправильно: POST /users/42 для апдейта.
✅ Правильно: PUT или PATCH.
Почему: POST предназначен для создания.

Ошибка 2: PUT с частичными данными

❌ Неправильно: PUT /users/42 только с email.
✅ Правильно: PATCH для частичного апдейта.
Почему: PUT заменяет ресурс целиком.

Ошибка 3: GET меняет данные

❌ Неправильно: GET /users/42/delete.
✅ Правильно: DELETE /users/42.
Почему: GET должен быть безопасным.

Ошибка 4: Нет Location при 201

❌ Неправильно: 201 без ссылки на ресурс.
✅ Правильно: вернуть Location.
Почему: клиент должен знать URL созданного объекта.

Ошибка 5: Тело ответа при 204

❌ Неправильно: возвращать JSON при 204.
✅ Правильно: 204 без тела.
Почему: 204 означает «нет контента».

Ошибка 6: Глаголы в URL

❌ Неправильно: /createUser.
✅ Правильно: /users.
Почему: REST использует ресурсы, не действия.

Best Practices

  • Используйте существительные в URL.
  • POST только для создания.
  • PUT для полной замены, PATCH для частичной.
  • Возвращайте корректные статусы (201, 200, 204, 404).
  • Валидируйте данные и давайте понятные ошибки.
  • Для списков используйте пагинацию.

Часто спрашивают на собеседованиях

  • Чем POST отличается от PUT?
  • Почему PUT идемпотентен?
  • Когда использовать PATCH?
  • Что возвращать при 201 и 204?
  • Почему GET не должен менять данные?
✅ Вывод: после этой лекции CRUD перестаёт быть «магией».

Заключение

CRUD — это основа REST API.
✅ Вывод: держите связь «метод → действие → статус», и API будет понятным.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «CRUD операции детально»

Пройти тест →