HTTP-методы

Что такое HTTP

HTTP (HyperText Transfer Protocol) — это протокол по которому браузер и сервер общаются друг с другом. Проще говоря — набор правил как задавать вопросы и давать ответы.

Ты вводишь адрес сайта в браузере → браузер отправляет запрос на сервер → сервер возвращает ответ → браузер показывает страницу. Всё что ты видишь в интернете работает именно так.

Каждый клик, каждая картинка, каждая кнопка — это отдельный запрос и ответ. HTTP просто описывает как именно они должны выглядеть чтобы обе стороны друг друга понимали.

Анатомия HTTP-сообщения

HTTP-сообщение — это просто текст. Никакой магии. Запрос и ответ имеют одинаковую структуру из трёх частей.

Запрос (Request) — от клиента к серверу

Ответ (Response) — от сервера к клиенту

Три части подробно

Стартовая строка — всегда одна, всегда первая. В запросе: метод + путь + версия. В ответе: версия + код статуса + текст. Больше ничего.

Заголовки (Headers) — главный инструмент управления HTTP. Формат жёсткий: Имя: Значение, по одному на строку. Заголовки — это инструкции, а не данные.

Пустая строка — обязательный разделитель. Сервер читает заголовки до пустой строки, затем переключается на чтение тела. Без неё протокол сломается.

Тело (Body) — собственно данные. У GET и DELETE тела обычно нет. У POST/PUT/PATCH — есть. Формат описывается заголовком Content-Type.

Анатомия URL

В стартовой строке запроса стоит путь — /api/users/42. Но клиент сначала разбирает полный URL чтобы понять куда подключаться и что запрашивать.

https://api.example.com:8443/api/users/42?active=true&limit=10#section2
└──┬──┘  └──────┬────────┘└┬─┘└─────┬─────┘└──────────┬────────┘└───┬──┘
scheme       host        port     path             query        fragment

Из всего URL в HTTP-запрос попадают только path + query:

GET /api/users/42?active=true&limit=10 HTTP/1.1
Host: api.example.com

Что такое HTTP-метод

HTTP — протокол прикладного уровня поверх TCP. Когда браузер обращается к серверу, первое что он указывает — метод (иногда его называют verb, глагол). Метод говорит серверу: что именно ты хочешь сделать с ресурсом.

GET /api/users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer eyJhbGci...

Первая строка — стартовая: <МЕТОД> <путь> <версия>. Всё остальное — заголовки. Тело (если есть) идёт после пустой строки.

Два ключевых свойства методов

Безопасность (Safe)

Безопасный метод не изменяет состояние сервера — только читает данные. Можно вызывать сколько угодно раз без побочных эффектов.

Идемпотентность (Idempotent)

Идемпотентный метод при повторном вызове с теми же параметрами даёт тот же результат. Это важно для ретраев: если соединение оборвалось — можно безопасно повторить запрос.

* PATCH может быть идемпотентным если реализован корректно, но по спецификации — гарантии нет.

Вложенность: безопасность ⊂ идемпотентность

Все три безопасных метода одновременно идемпотентны. Это не случайность — если метод не меняет состояние вообще, то повторный вызов по определению даст тот же результат. Безопасность автоматически влечёт идемпотентность.

Обратное неверно: DELETE удаляет ресурс (изменение!), но второй DELETE уже ничего не меняет — ресурса нет. Безопасным не является, а идемпотентным — да.

Методы по одному

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

Самый используемый метод. Не имеет тела. Параметры передаются в URL через query string.

GET /api/users?page=2&limit=20 HTTP/1.1
Host: api.example.com

HTTP/1.1 200 OK
Content-Type: application/json

[
  { "id": 21, "name": "Алексей" },
  { "id": 22, "name": "Мария" }
]

• Результат GET можно и нужно кешировать — браузер и CDN делают это автоматически. Веб-сервер кеширует GET только если кеш явно настроен.
• Данные в URL видны в логах, истории браузера, заголовке Referer — не передавай пароли через GET.
• Если кеширование на веб-сервере включено — кешируются только GET и HEAD, остальные методы никогда.

Типичные коды: 200 OK · 404 Not Found · 304 Not Modified

POST — создать ресурс

Создаёт новый ресурс. Данные — в теле. Не идемпотентный: два одинаковых POST создадут две записи.

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Новый пользователь",
  "email": "user@example.com"
}

HTTP/1.1 201 Created
Location: /api/users/43
Content-Type: application/json

{ "id": 43, "name": "Новый пользователь", "email": "user@example.com" }

• Код успешного создания — 201 Created, а не 200.
• Заголовок Location указывает URL созданного ресурса — хороший тон.
• При ретрае без контроля идемпотентности можно получить дубликаты. Решение — Idempotency-Key.

PUT — полностью заменить ресурс

Заменяет ресурс целиком. Передаёшь полное новое представление — сервер заменяет старое на новое. Идемпотентный.

PUT /api/users/43 HTTP/1.1
Content-Type: application/json

{
  "name": "Изменённое имя",
  "email": "changed@example.com"
}

PATCH — частично обновить ресурс

Обновляет только указанные поля. Не нужно передавать весь объект.

PATCH /api/users/43 HTTP/1.1
Content-Type: application/json

{ "email": "only_email_changed@example.com" }

• PATCH экономнее PUT — не нужно гонять весь объект по сети.
• Меняешь всё — PUT, меняешь часть — PATCH.

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

Удаляет ресурс. Идемпотентный: повторный DELETE вернёт 404, но состояние сервера одинаковое — ресурса нет.

DELETE /api/users/43 HTTP/1.1

HTTP/1.1 204 No Content

• 204 No Content — нормальный ответ на DELETE, тело пустое.
• Второй DELETE вернёт 404 — это не ошибка, это нормальное идемпотентное поведение.

HEAD — только заголовки, без тела

Как GET, но сервер возвращает только заголовки — без тела. Используется чтобы проверить существование ресурса или узнать метаданные без скачивания.

OPTIONS — что умеет сервер

Запрашивает список поддерживаемых методов. Ключевой элемент механизма CORS preflight.

OPTIONS /api/users HTTP/1.1
Origin: https://frontend.example.com
Access-Control-Request-Method: DELETE

HTTP/1.1 200 OK
Allow: GET, POST, PUT, PATCH, DELETE, OPTIONS
Access-Control-Allow-Origin: https://frontend.example.com
Access-Control-Allow-Methods: GET, POST, DELETE

• Браузер автоматически отправляет OPTIONS перед «небезопасными» кросс-доменными запросами.
• На веб-сервере нужно явно обрабатывать OPTIONS и возвращать правильные CORS-заголовки, иначе браузер заблокирует запрос.
• Тонны OPTIONS в логах — это нормально, браузеры делают preflight.

Коды ответа

Коды делятся на пять классов по первой цифре.

2xx — успех

3xx — перенаправление

4xx — ошибка клиента

5xx — ошибка сервера

Итог

HTTP-методы — это соглашение. Технически никто не мешает делать DELETE через POST. Но соблюдение семантики даёт три преимущества: