REST API

HTTP методы: основы

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

HTTP методы: основы

REST API

HTTP методы: основы

Введение: пульт управления 🎛️

Представьте панель управления: у каждой кнопки своё действие — «показать», «создать», «изменить», «удалить».
HTTP‑методы — это такие же кнопки для работы с ресурсами API.
💡 Совет: метод отвечает на «что делаем», а URL — на «с чем».
Вывод: метод = действие, ресурс = объект действия.

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

Проблема: без чётких методов API превращается в «кашу»: один и тот же URL делает всё подряд.
Решение: стандартизировать методы и их смысл — чтение, создание, обновление, удаление.
Вывод: правильные методы делают API понятным и предсказуемым.

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

HTTP‑методы делают поведение API предсказуемым и понятным для клиента. Если выбрать правильный метод, ошибок меньше и логика прозрачнее.
Как это работает:
  1. Определяем действие (получить, создать, обновить, удалить).
  2. Выбираем метод: GET, POST, PUT, PATCH или DELETE.
  3. Сервер выполняет действие и возвращает корректный статус‑код.
Вывод: верный метод = понятный контракт между клиентом и сервером.

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

  • Метод (Method) — действие над ресурсом.
  • Ресурс (Resource) — объект: курс, пользователь, заказ.
  • Endpoint — URL + метод.
  • Body (тело запроса) — данные, которые мы отправляем.
  • Safe‑метод — не меняет данные (чтение).
  • Идемпотентность — повтор запроса даёт тот же результат.
  • Status code — итог запроса (200, 201, 204 и т.д.).
Вывод: термины задают «язык» работы с API.

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

  • GET не меняет состояние (только чтение).
  • POST не идемпотентен (повтор создаёт дубликаты).
  • PUT заменяет целиком, PATCH — частично.
  • DELETE идемпотентен (после первого раза ресурса уже нет).
  • Body — обычно в POST/PUT/PATCH, у GET — редко и не рекомендуется.
  • Метод + URL = действие + ресурс.
Вывод: эти правила — база, без них API становится непредсказуемым.

1. GET — получить данные

Назначение: запросить ресурс без изменений.
Простыми словами: мы просто читаем и ничего не меняем.
Аналогия: открыть каталог и посмотреть товары.
Пример:
GET /courses?level=beginner
🔎 Как это происходит на практике:
  1. Клиент делает GET /courses?level=beginner.
  2. Сервер возвращает 200 OK и список курсов.
  3. Клиент отображает данные, ничего не меняя на сервере.
Характеристики:
  • ✅ safe и идемпотентный;
  • ✅ можно кешировать;
  • ❗ тело запроса не используется.
Когда использовать: чтение, поиск, фильтрация.
Вывод: GET = «покажи».

2. POST — создать или запустить действие

Назначение: создать новый ресурс или запустить процесс.
Простыми словами: сервер создаёт что‑то новое по нашим данным.
Аналогия: оформить заказ.
Пример:
POST /courses{  "title": "JS Basics"}
🔎 Как это происходит на практике:
  1. Клиент отправляет POST /courses с данными.
  2. Сервер создаёт ресурс или запускает процесс.
  3. Возвращает 201 Created (часто с телом и Location).
Характеристики:
  • ❗ не идемпотентный;
  • ✅ данные в теле запроса;
  • ✅ чаще всего возвращает 201 + тело.
Когда использовать: создание, отправка формы, операции типа «оплатить».
Вывод: POST = «создай/запусти».

3. PUT — полная замена

Назначение: заменить ресурс целиком.
Простыми словами: мы отправляем полную новую версию объекта.
Аналогия: переписать анкету заново.
Пример:
PUT /courses/10{  "title": "JS Advanced",  "level": "advanced"}
🔎 Как это происходит на практике:
  1. Клиент отправляет PUT /courses/10 с полной версией объекта.
  2. Сервер полностью заменяет ресурс.
  3. Повторный запрос оставляет тот же результат.
Характеристики:
  • ✅ идемпотентный;
  • ✅ ожидает полный объект;
  • ❗ может перезаписать поля.
Когда использовать: полное обновление ресурса.
Вывод: PUT = «замени полностью».

4. PATCH — частичное обновление

Назначение: изменить только часть ресурса.
Простыми словами: отправляем только то, что меняется.
Аналогия: поменять один пункт в анкете.
Пример:
PATCH /courses/10{  "level": "advanced"}
🔎 Как это происходит на практике:
  1. Клиент отправляет PATCH /courses/10 только с изменениями.
  2. Сервер обновляет указанные поля.
  3. Остальные данные остаются без изменений.
Характеристики:
  • ⚠️ идемпотентность зависит от реализации;
  • ✅ передаются только изменённые поля;
  • ✅ удобен для частичных правок.
Когда использовать: обновление одного или нескольких полей.
Вывод: PATCH = «измени часть».

5. DELETE — удалить ресурс

Назначение: удалить объект.
Простыми словами: ресурс исчезает из системы.
Аналогия: выбросить документ в архив.
Пример:
DELETE /courses/10
🔎 Как это происходит на практике:
  1. Клиент отправляет DELETE /courses/10.
  2. Сервер удаляет ресурс.
  3. Повторный DELETE не должен ломать API и обычно возвращает 204.
Характеристики:
  • ✅ идемпотентный;
  • ✅ обычно отвечает 204 No Content;
  • ❗ повторный DELETE не должен ломать API.
Когда использовать: удаление записей.
Вывод: DELETE = «убери ресурс».

6. Идемпотентность и safe‑методы

Назначение: понять, какие запросы можно безопасно повторять.
Простыми словами: повтор не должен менять итог.
Аналогия: нажимать кнопку лифта много раз — лифт всё равно приедет один раз.
Пример:
PUT /users/7 (повтор не меняет итог)POST /users (повтор создаёт дубликат)
🔎 Как это происходит на практике:
  1. Клиент повторяет PUT /users/7 из‑за сбоя сети.
  2. Сервер остаётся в том же состоянии (идемпотентность).
  3. Для POST повтор может создать дубликат.
Характеристики:
  • ✅ GET/PUT/DELETE — идемпотентные;
  • ❗ POST — не идемпотентный;
  • ✅ safe‑методы: GET/HEAD/OPTIONS.
Когда использовать: при ретраях и нестабильной сети.
Вывод: идемпотентность = безопасность повторов.

Сравнение методов

МетодСмыслИдемпотентныйSafeЕсть тело запроса
GETчтение
POSTсоздание/действие
PUTполная замена
PATCHчастичное обновление⚠️
DELETEудаление
Вывод: выбор метода зависит от действия и идемпотентности.

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

  • PUT vs PATCH? PUT заменяет полностью, PATCH меняет часть.
  • Почему POST не идемпотентен? повтор создаёт новые ресурсы.
  • DELETE идемпотентен? да, итог один — ресурса нет.
  • GET может менять данные? нет, это нарушение safe‑принципа.
  • Где тело запроса? в POST/PUT/PATCH.
Вывод: эти различия — база для интервью.

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

Ошибка 1: POST для чтения

POST /courses/search
GET /courses?query=...
Почему: чтение = GET.
Практический пример:
GET /courses?level=beginner

Ошибка 2: PUT вместо PATCH для мелкой правки

❌ отправляем весь объект ради одного поля
✅ PATCH с изменёнными полями
Почему: PUT может случайно перезаписать поля.

Ошибка 3: DELETE возвращает 200 с телом

❌ 200 + JSON
✅ 204 No Content
Почему: успешное удаление не требует тела.

Ошибка 4: GET с изменением данных

GET /courses/10/delete
DELETE /courses/10
Почему: GET должен быть безопасным.

Ошибка 5: PATCH с инкрементом без объяснения

❌ PATCH { "views": {"$inc": 1} }
✅ документировать неидемпотентность
Почему: клиент должен понимать поведение.

Best Practices

  • Используйте GET только для чтения.
  • POST — для создания, PUT — для полной замены, PATCH — для частичных правок.
  • DELETE возвращает 204 без тела.
  • Документируйте идемпотентность PATCH.
  • Всегда описывайте, какие поля принимает тело запроса.

Заключение

🎯 Методы — это «язык действий» API.
🎯 Правильный метод = предсказуемый результат.
🎯 Идемпотентность защищает от дублей и ошибок.
Теперь ты умеешь выбирать метод так, как это делают сильные API‑команды.
🎯

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

Закрепите материал — пройдите тест по теме «HTTP методы: основы»

Пройти тест →