HTTP-протокол

HTTP — прикладной протокол обмена сообщениями между клиентом и сервером. Модель request-response не хранит бизнес-состояние автоматически: связь двух запросов приложение организует через cookie, токен, данные сервера и другие механизмы.

URL

scheme://host:port/orders/42?details=true#history
  • scheme — протокол доступа, например HTTPS;
  • host — доменное имя, разрешается через DNS;
  • port — порт сервера;
  • /orders/42 — path;
  • details=true — query;
  • history — fragment, браузер не отправляет его серверу в HTTP-запросе.

URL идентифицирует ресурс. Метод определяет намерение операции над ним.

HTTP/1.1 запрос и ответ

GET /orders/42 HTTP/1.1
Host: api.example.com
Accept: application/json
If-None-Match: "order-42-v3"
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 28
ETag: "order-42-v4"
 
{"id":42,"status":"PAID"}

Сообщение состоит из start line, headers, пустой строки и необязательного body. В HTTP/2 и HTTP/3 данные кодируются фреймами, но семантика методов, заголовков и status codes сохраняется.

Методы

МетодОбычный смыслSafeIdempotent
GETпрочитать ресурсдада
HEADполучить headers без body ответадада
POSTсоздать подчинённый ресурс или запустить командунетнет
PUTполностью заменить ресурс по известному URIнетда
PATCHчастично изменить ресурснетне гарантируется
DELETEудалить ресурснетда

Safe означает отсутствие ожидаемого изменения состояния. Idempotent — повтор того же запроса имеет тот же целевой эффект, хотя логи, метрики и время ответа могут различаться.

POST можно сделать идемпотентным на уровне API: клиент отправляет idempotency key, а сервер сохраняет результат первой обработки и возвращает его при повторе. Ключ должен иметь область действия и срок хранения.

Status codes

  • 1xx — промежуточная информация;
  • 2xx — успешная обработка;
  • 3xx — перенаправление или использование cache;
  • 4xx — запрос клиента нельзя обработать в текущем виде;
  • 5xx — сервер не выполнил корректный запрос.

Часто путают:

  • 400 — синтаксис/валидация запроса;
  • 401 — требуется аутентификация;
  • 403 — личность известна, но доступа нет;
  • 404 — ресурс не найден или намеренно скрыт;
  • 409 — конфликт с текущим состоянием;
  • 429 — превышен лимит;
  • 500 — необработанная ошибка сервера;
  • 502/503/504 — проблемы gateway, доступности или timeout upstream.

Headers и представление

Content-Type описывает фактическое body, Accept — желаемый формат ответа. Content-Encoding сообщает о сжатии представления, а Transfer-Encoding относится к передаче сообщения.

Заголовки регистронезависимы по имени. Нельзя без ограничения доверять Host, Forwarded и X-Forwarded-*: корректность зависит от доверенной цепочки proxy.

Кэширование

Cache-Control задаёт политику. Валидаторы позволяют условный запрос:

  • ETag + If-None-Match;
  • Last-Modified + If-Modified-Since.

При неизменившемся ресурсе сервер отвечает 304 Not Modified без обычного body. Ответы с авторизацией и персональными данными требуют особенно явной политики cache.

Соединения и версии

  • HTTP/1.1 переиспользует TCP-соединения, но параллельность часто требует нескольких соединений;
  • HTTP/2 мультиплексирует streams в одном TCP-соединении и сжимает headers;
  • HTTP/3 переносит HTTP-семантику поверх QUIC/UDP и уменьшает влияние потери пакета между независимыми streams.

Версия сама по себе не исправляет медленный handler или зависимость.

Размеры и timeout

Протокол не задаёт универсальный предел длины URL или body. Ограничения устанавливают браузер, proxy, сервер и приложение. Их согласуют для:

  • request line и headers;
  • upload/body;
  • времени чтения, обработки и отправки;
  • числа соединений и запросов.

Слишком большой лимит создаёт риск исчерпания памяти, слишком маленький — неожиданные 4xx.

Безопасность

HTTP без TLS передаёт данные открыто. HTTPS — HTTP поверх TLS; детали в SSL. TLS не отменяет проверку доступа, CSRF-защиту, безопасные cookie, валидацию входа и запрет утечки секретов в URL/логах.

На собеседовании

Почему GET не должен менять состояние? Клиенты, crawler и cache имеют право повторять или заранее выполнять safe-запросы.

PUT и PATCH одинаково идемпотентны? PUT по семантике идемпотентен. Идемпотентность PATCH зависит от формата изменения: «установить 5» и «увеличить на 5» ведут себя по-разному.

Связанные заметки: Версии протокола HTTP, Отличия POST и PUT и PATCH методов HTTP, MVC.