Логотип Workflow

Article

Updated at:

Http Methods Get Post Put Delete

Stage 1. HTTP Methods: GET, POST, PUT, DELETE

Когда новичок впервые смотрит на API, оно может выглядеть как случайный набор URL. На практике общение между приложением и сервером всегда идёт по протоколу. Протокол — это набор общих правил. Браузер, мобильное приложение и сервер могут работать вместе только потому, что понимают одни и те же правила.

В веб-разработке базовым протоколом является HTTP. HTTP описывает, как клиент отправляет запрос и как сервер возвращает ответ. Клиентом может быть вкладка браузера, мобильное приложение или другой backend-сервис. Сервер принимает запрос, выполняет бизнес-логику и отправляет результат обратно.

HTTPS — это защищённая версия HTTP. Буква “S” означает, что используется TLS-шифрование. В обычном HTTP трафик по сети можно прочитать или изменить, если попасть между клиентом и сервером. В HTTPS данные запроса и ответа шифруются при передаче. Для реальных продуктов вход пользователя и персональные данные должны работать только через HTTPS.

Client and server over HTTP/HTTPS

У запроса обычно есть три базовые части:

  • метод (GET, POST, PUT, DELETE)
  • путь (например, /tasks)
  • необязательное тело запроса (данные, которые отправляем на сервер)

У ответа обычно есть:

  • статус-код (200, 201, 404 и другие)
  • необязательное тело ответа

Главная идея этой темы: HTTP-метод показывает намерение операции.

МетодПростое значениеТипичное применение для новичка
GETПрочитать данныеЗагрузить страницу или список
POSTСоздать данныеДобавить новую запись
PUTПолностью заменить существующие данныеОбновить существующую запись
DELETEУдалить данныеУдалить существующую запись

Чтобы было практично, возьмём один реалистичный сценарий: простое приложение со списком задач.

Пользователь открывает приложение и хочет увидеть все задачи. Клиент отправляет GET /tasks. Сервер возвращает текущий список. Такая операция должна только читать данные и не менять их.

Дальше пользователь создаёт новую задачу: «Купить молоко». Клиент отправляет POST /tasks с данными в теле запроса, например с текстом задачи. Сервер создаёт новую запись задачи и возвращает созданный объект.

Позже пользователь редактирует задачу. Приложение уже знает id задачи 7, поэтому отправляет PUT /tasks/7 с новым полным состоянием, например с обновлённым текстом и признаком выполнения. Сервер заменяет сохранённое состояние этой задачи.

В конце пользователь удаляет задачу, и приложение отправляет DELETE /tasks/7. Сервер удаляет запись и подтверждает успешную операцию.

Частая ошибка новичка — использовать POST для всего. Сначала это работает, но потом API становится трудно читать: каждый endpoint выглядит как «сделай что-то», и клиентам сложнее предсказать поведение по семантике протокола.

Другая ошибка — менять данные через GET. Например, если GET /tasks/7/complete отмечает задачу выполненной, то обновление страницы, prefetch в браузере или повтор запроса могут случайно изменить состояние. GET должен оставаться только для чтения.

На этом этапе не нужны сложные конструкции. Запомните безопасовую базу:

  1. Нужно прочитать данные: используем GET.
  2. Нужно создать новую запись: используем POST.
  3. Нужно заменить существующую запись по известному id: используем PUT.
  4. Нужно удалить запись: используем DELETE.

Если это соответствие соблюдается, API проще читать, проще отлаживать и безопаснее расширять даже на раннем уровне. Главная польза не в «академической правильности». Главная польза — предсказуемое поведение и для разработчика, и для пользователя.

Авторизуйтесь чтоб пройти тесты

Quiz

Проверьте, что вы усвоили

Practice

Интерактивная практика

Выполните задания и сразу проверьте ответ.