HTTP как основа веб-интеграций
HTTP
Современная HTTP-экосистема
HTTP — центр веба и большинства API. Вокруг него выстраиваются транспорт, шифрование, имена, кэш, прокси, веб-серверы и форматы обмена. Ниже — карта компонентов, которую удобно держать под рукой при разработке и разборе инцидентов. Детали по каждому блоку — в связанных статьях; на этой странице — версии HTTP, цикл запроса и отладка.
Версии и семантика
| Версия | Транспорт | Что запомнить |
|---|---|---|
| HTTP/1.1 | TCP | Методы GET, HEAD, POST, PUT, PATCH, DELETE; статус-коды; stateless; persistent connections (keep-alive); кэш (RFC 9111); MIME-типы (Content-Type). База совместимости и многих legacy API. |
| HTTP/2 | TCP + TLS (де-факто) | Мультиплексирование в одном соединении, сжатие заголовков HPACK, бинарные кадры. Server Push в спецификации устарел — на практике вместо него preload и оптимизация критического пути. Поверх HTTP/2 часто строят gRPC (RPC, Protobuf). |
| HTTP/3 | QUIC (UDP) | TLS 1.3 встроен в QUIC; независимые потоки без TCP head-of-line blocking. Стандарт для современных браузеров и CDN; ускорение заметно на мобильных сетях и при потерях пакетов. |
Сравнение потоков и HOL — ниже на странице, эволюция HTTP, таблица RFC — справочник HTTP.
Транспорт, адреса и имена
- TCP/IP (IPv4, IPv6) — основа HTTP/1.1 и HTTP/2; установка соединения, порты (80, 443). Четыре уровня стека, PDU и инкапсуляция — модель TCP/IP; детали TCP и UDP — там же.
- QUIC поверх UDP — транспорт HTTP/3; см. справочник протоколов.
- UNIX domain sockets — связь процессов на одной машине (типично reverse proxy ↔ backend), без сетевого стека.
- URI / URL — схема (
https), хост, путь, query, кодирование; см. URI и URL. - DNS — кэш браузера/ОС, затем рекурсивный резолвер и иерархия Root → TLD → авторитативный сервер; HTTP начинается только после получения IP. Участвует в балансировке и выборе CDN-узла. См. DNS и пошаговый резолв.
HTTPS, доверие и периметр
HTTPS — HTTP внутри TLS (преемник SSL):
- Симметричное шифрование трафика (AES, ChaCha20) после обмена ключами — один общий сессионный секрет на соединение.
- Асимметричный обмен (RSA, ECDH) на этапе рукопожатия — согласование секрета и проверка сертификата без передачи закрытого ключа сервера по сети.
- Целостность — хеши в цифровой подписи сертификата (SHA-2); подпись создаётся закрытым ключом CA, браузер проверяет открытым.
- Доверие — цепочка сертификатов X.509 до доверенного CA; в сертификате лежит открытый ключ сайта.
Роли открытого и закрытого ключа, подпись и гибридная схема (асимметрия на handshake, симметрия на HTTP) — в асимметричной криптографии.
WAF (Web Application Firewall) анализирует HTTP(S)-запросы на границе (SQLi, XSS, частота) — часто на CDN или reverse proxy. См. прокси и CDN, шифрование и SSH. Сводный чек-лист по API (HTTPS, OAuth, rate limit, gateway) — 12 советов по безопасности API.
Прокси, CDN и балансировка
| Роль | Назначение |
|---|---|
| Forward proxy | Клиент выходит в интернет через посредника (корпоративная сеть, фильтрация). |
| Reverse proxy | Точка входа на сервер (nginx, HAProxy, Traefik), TLS-терминация, маршрутизация. |
| API Gateway | Единая точка для микросервисов — auth, rate limit, маршруты /api/*. Полный продакшн-контур (registry, кэш, брокер, метрики, логи) — карта из 9 компонентов. |
| CDN | Кэш и edge-узлы ближе к пользователю; балансировка; Squid, Varnish, Apache Traffic Server, облачные CDN. |
См. магистрали и CDN, сетевое администрирование.
Серверы, клиенты и представление
- Веб-серверы — nginx / OpenResty, Apache, IIS (Windows), Tomcat и servlet-контейнеры (Java). См. веб-серверы.
- Браузеры (Chrome, Firefox, Safari) — HTTP-клиент, парсинг HTML (HTML4/HTML5), CSS, JavaScript. См. браузеры, HTML.
Сервисы и каналы поверх HTTP
| Подход | Кратко |
|---|---|
| REST | Ресурсы, методы HTTP, часто JSON. См. API. |
| SOAP | XML-конверты, WSDL. См. SOAP. |
| GraphQL | Один эндпоинт, клиент задаёт поля ответа. См. REST, GraphQL и gRPC. |
| gRPC | RPC поверх HTTP/2, Protobuf. См. REST, GraphQL и gRPC. |
| WebSocket | Постоянный двунаправленный канал после HTTP Upgrade (чаты, котировки). См. WebSocket. |
Краулинг, захват трафика и наблюдаемость
robots.txt— правила для поисковых роботов (какие пути не индексировать).- Wireshark, tcpdump — захват и разбор пакетов на всех уровнях. См. диагностика сети, трафик.
- OpenTelemetry и заголовки
traceparent/X-Request-ID— сквозная трассировка запросов между сервисами (см. наблюдаемость ниже).
При "сайт тормозит" пройдите слои сверху вниз: DNS → TCP/QUIC → TLS → HTTP-версия → CDN/кэш → backend. При "API отдаёт 403" проверьте WAF, CORS и авторизацию до разбора бизнес-логики.
Полный цикл одного HTTP-взаимодействия
Практический цикл запроса включает больше шагов, чем метод + URL.
- Клиент формирует URL, метод, заголовки и тело.
- DNS-резолвер находит IP-адрес домена (при промахе кэша — Root → TLD → авторитативный сервер).
- Транспорт создаёт соединение (TCP для HTTP/1.1 и HTTP/2; QUIC для HTTP/3).
- Для HTTPS выполняется TLS-рукопожатие.
- Клиент отправляет запрос и ждёт ответ.
- Сервер обрабатывает запрос, может обратиться к БД и кэшам.
- Сервер возвращает код ответа, заголовки и тело.
- Клиент применяет политику повторов, кэша, редиректов и логирования.
Этот цикл помогает диагностировать ошибки. Таймаут до ответа сервера и ошибка TLS относятся к разным этапам, поэтому требуют разных действий.
Что проверять в HTTP при отладке
Минимальный чек-лист для разработчика и инженера:
- Метод и путь соответствуют контракту API.
- Код ответа отражает реальный бизнес-результат.
Content-Typeсовпадает с фактическим форматом тела.- Для защищённых операций присутствуют
Authorizationи корректные права. - Для кэша используются
ETag,Cache-Control,If-None-MatchилиIf-Modified-Since. - Для трассировки есть
X-Request-IDилиtraceparent. - Для лимитов явно заданы
429иRetry-After. - Для HTTPS включены HSTS и актуальные версии TLS.
Кэширование HTTP на практике
HTTP-кэш работает на стороне браузера, CDN и reverse-proxy.
Cache-Control: max-age=...задаёт срок жизни ответа.ETagиIf-None-Matchвключают условные запросы.Last-ModifiedиIf-Modified-Sinceдают упрощённую валидацию.- Ответ
304 Not Modifiedэкономит трафик и ускоряет интерфейс. Varyопределяет, какие заголовки влияют на вариант ответа.
Хорошая стратегия кэша снижает нагрузку на backend и стоимость инфраструктуры.
Безопасность HTTP и HTTPS
HTTPS защищает канал связи, а безопасная интеграция включает дополнительные меры:
- TLS 1.2 или TLS 1.3.
- HSTS (
Strict-Transport-Security). - Безопасные cookie (
Secure,HttpOnly,SameSite). - Защита от подмены типа (
X-Content-Type-Options: nosniff). - Ограничение встраивания (
X-Frame-Optionsили CSPframe-ancestors). - Контроль CORS для браузерных клиентов.
HTTPS закрывает конфиденциальность и целостность трафика, а остальные механизмы закрывают риски на уровне браузера и API.
В рунет-дискурсе
HTTP в форумной речи иногда смешивают с "вебом вообще"; в баг-репорте полезны метод (GET/POST), URL, код ответа (404, 500) и фрагмент тела ответа. Незащищённый HTTP сегодня браузеры ограничивают, поэтому рабочий веб для пользователя — почти всегда HTTPS.
В разговорах "сайт с шифровкой" почти всегда означает HTTPS (TLS): замок в адресной строке и сертификат домена. Это защита канала до сервера, а не гарантия, что сервер честный или что данные в базе зашифрованы.
Старые мемы про "HTTP — для лохов" отражали эпоху смешанного контента; сегодня браузеры помечают незащищённые формы и поощряют HSTS. Отличие TLS от "шифровки файла" и от хеша пароля — в разделе про шифрование. Мост "культура ↔ протокол" — 2.04 / 125. Указатели — Неолурк (Http), Https; куки передаются внутри того же HTTPS-запроса.
HTTP и наблюдаемость в продакшене
Для устойчивой эксплуатации каждый HTTP-запрос должен быть заметен в логах и метриках.
- Логи фиксируют
method,path,status,duration,request_id. - Метрики считают RPS, latency, процент 4xx/5xx, ошибки по эндпоинтам.
- Трассировка связывает вызовы между сервисами через
traceparent. - Алерты срабатывают на рост 5xx, таймаутов и p95/p99 latency.
Так HTTP становится не только форматом запроса, но и управляемым эксплуатационным контуром.
RFC и документация для углубления
Базовые источники для системного понимания протокола:
- RFC 9110 — HTTP Semantics.
- RFC 9111 — HTTP Caching.
- RFC 9112 — HTTP/1.1.
- RFC 9113 — HTTP/2.
- RFC 9114 — HTTP/3.
- MDN Web Docs по HTTP-заголовкам и статусам.
Структура HTTP-запроса
HTTP-запрос состоит из трёх частей - стартовая строка, заголовок и тело запроса.
Стартовая строка указывает метод, путь и версию протокола. Пример:
GET /posts/1 HTTP/1.1
Стартовая строка - это самая первая строка запроса, которая формируется по шаблону:
<Метод> <Путь> <Версия протокола>
Методом называется действие, которое хочет выполнить клиент (GET, POST, PUT, PATCH, DELETE и другие).
Путь - это URL-адрес на сервере, указывающий, к какому ресурсу обращается клиент.
Версия протокола - это версия HTTP, которую использует клиент (HTTP/1.1, HTTP/2, HTTP/3).
Play ITЗагрузка интерактивного демо…
Заголовок содержит дополнительную информацию о запросе. Это блок метаданных, передаваемых вместе с запросом. Заголовки содержат информацию о клиенте, теле запроса, авторизации, формате данных и многое другое.
Заголовок формируется по формату:
<Имя заголовка>: <Значение>
Заголовки бывают общие, кастомные, заголовки запроса и заголовки сущности. Мы отдельно их рассмотрим.
Тело запроса является необязательным и используется для методов POST, PUT, PATCH. Тело содержит полезные данные, отправляемые серверу. К примеру, JSON:
{
"title": "foo",
"body": "bar",
"userId": 1
}
Формат данных в теле определяется через заголовок Content-Type, HTTP-заголовок, который указывает тип содержимого в теле запроса или ответа. Пример:
Content-Type: text/html; charset=UTF-8
Это означает, что тело сообщения содержит HTML-документ, использующий кодировку UTF-8. А для JSON указывается application/json. Важно понимать, что путь в запросах представляет собой часть URI после домена, которая указывает на конкретный ресурс. К примеру, если Host указан как api.example.com, а в стартовой строке указан путь как /api/users, то полный URI будет http://api.example.com/api/users. Мы же помним разницу между URL и URI?
Пути могут содержать:
- параметры пути - /users/123
- параметры строки запроса (или просто параметры запроса) - ?sort=date&limit=10
Учитывая всю эту кучу информации, нам понадобится шаблон для составления сложных запросов, который бы включал все ключевые элементы:
<МЕТОД> <ПУТЬ> <ВЕРСИЯ ПРОТОКОЛА>
Host: <ХОСТ>
[ЗАГОЛОВОК 1]: <ЗНАЧЕНИЕ 1>
[ЗАГОЛОВОК 2]: <ЗНАЧЕНИЕ 2>
...
[ЗАГОЛОВОК N]: <ЗНАЧЕНИЕ N>
<ТЕЛО ЗАПРОСА (необязательно)>
Такой шаблон может пригодиться при тестировании API вручную, например, через Telnet, Netcat или текстовый файл, а также при написании скриптов.
Для простоты лучше использовать Postman и curl — они автоматически добавляют нужные заголовки и корректно формируют тело. Полный разбор CLI-запросов — утилита curl, curl / fetch — примеры.
Анализатор запросов
Play ITЗагрузка интерактивного демо…
Версии HTTP
Когда и какие версии HTTP использовать?
HTTP/0.9 - простая версия 1991 года выпуска. Это очень простой протокол, там есть только GET, без заголовков и статус-кодов.
HTTP/1.0 выпущена в 1996 году, туда как раз и были добавлены заголовки, коды состояния и MIME-типы.
HTTP/1.1 выпущен в 1999 году и используется до сих пор. Здесь добавили поддержку keep-alive (persistent connections), pipelining, хостинга на одном IP.
Keep-Alive — это механизм, позволяющий повторно использовать одно TCP-соединение для нескольких HTTP-запросов и ответов. Просто добавляется заголовок Connection: keep-alive. Если он не указан, в HTTP/1.1 добавляется по умолчанию, чтобы его отключить надо указать close. Это уменьшает задержку, связанную с установкой новых TCP-соединений, ускоряет загрузку страницы за счёт повторного использования соединения, и экономит ресурсы сервера.
Pipelining — возможность отправки нескольких HTTP-запросов подряд по одному соединению без ожидания ответа на предыдущий, что ускоряет работу клиент-серверного взаимодействия. Но не все серверы его поддерживают, и требуется строгое соблюдение порядка ответов, при работе с прокси или брандмауэрами могут быть проблемы. В HTTP/2 pipelining заменён более мощным механизмом — мультиплексированием.
HTTP/2 появился в 2015, добавив бинарный протокол, мультиплексирование, сжатие заголовков, сервер push. В отличие от текстового формата HTTP/1.x, в HTTP/2 используется бинарный формат передачи данных, что позволяет более эффективно парсить данные, уменьшает вероятность ошибок при чтении запросов и ответов, а также использовать новые функции, такие как потоки и мультиплексирование.
Мультиплексирование - одна из ключевых особенностей HTTP/2, когда клиент может отправлять несколько запросов по одному TCP-соединению, не дожидаясь ответа на предыдущий. Это устраняет проблему последовательной загрузки ресурсов, снижает задержку (latency) и позволяет браузеру быстрее загружать страницы.
Заголовки часто повторяются между запросами. В HTTP/2 используется сжатие заголовков через алгоритм HPACK, который снижает объём данных, особенно при множестве небольших запросов.
Сервер Push (устарел в RFC 9113) позволял серверу заранее отправлять ресурсы (CSS, JS); сегодня чаще используют Link: rel=preload и оптимизацию критического пути.
HTTP/3 выпущен в 2022 году (RFC 9114). Транспорт — QUIC поверх UDP: надёжность, шифрование (TLS 1.3 встроен в QUIC) и управление потоками реализованы на транспортном уровне, а HTTP поверх QUIC сохраняет те же семантики методов, заголовков и статус-кодов.
HTTP/2 и HTTP/3 — потоки, TCP и head-of-line blocking
Чтобы понять разницу версий, полезно разделить потоки HTTP (логические запросы и ответы) и транспорт, который физически доставляет байты.
HTTP/2 — мультиплексирование на уровне HTTP, одна очередь TCP
Между клиентом и сервером обычно одно TLS-соединение и один TCP-канал. Внутри него HTTP/2 делит обмен на потоки (streams) — отдельные запросы и ответы (главная страница, CSS, скрипт, картинка). Данные разных потоков упаковываются в кадры (HEADERS, DATA и др.) и чередуются в одном TCP-потоке.
TCP видит единую последовательность пакетов с общим порядком доставки и общим контролем перегрузки. Пакеты TCP могут нести байты сразу нескольких HTTP/2-потоков — транспорт об этом "не знает".
При потере одного TCP-пакета приёмник ждёт его повторной передачи и не отдаёт приложению следующие пакеты, даже если в них уже лежат данные других HTTP/2-потоков. Это TCP head-of-line blocking (блокировка "головы очереди" на транспорте): один сбой на линии может заморозить все параллельные запросы в этом соединении.
HTTP/2 снял блокировку между запросами на уровне HTTP/1.1 (несколько запросов без ожидания ответа на предыдущий, без лимита "шесть соединений на домен"), но не убрал зависимость от упорядоченной доставки TCP.
HTTP/3 — мультиплексирование в QUIC
QUIC работает поверх UDP, но сам обеспечивает надёжность. У соединения QUIC есть независимые потоки со своим порядком и своим восстановлением после потерь. Потеря пакета в потоке загрузки скрипта не блокирует поток с HTML или стилями — задерживается только затронутый поток.
HTTP/3 переносит ту же модель запросов и ответов на этот транспорт. Практический выигрыш заметен при нестабильной сети (мобильный интернет, высокий RTT, потери пакетов) и при множестве мелких параллельных запросов.
| Уровень | HTTP/2 | HTTP/3 |
|---|---|---|
| Транспорт | TCP (+ TLS) | QUIC (UDP + встроенный TLS) |
| Где мультиплексируются запросы | Кадры HTTP/2 в одном TCP | Отдельные потоки QUIC |
| Потеря пакета | Может задержать все HTTP/2-потоки в соединении | Задерживает один QUIC-поток |
| Смена сети (Wi‑Fi → LTE) | Часто новое TCP/TLS-соединение | Connection ID QUIC, быстрее возобновление |
В HTTP/1.1 head-of-line blocking — это очередь ответов (pipelining) или лимит параллельных соединений. В HTTP/2 его снимают на уровне протокола HTTP, но остаётся TCP HOL — очередь пакетов одного сокета. HTTP/3 адресует именно транспортный случай.
Дополнительно у QUIC — шифрование по умолчанию и устойчивее перенос соединения при смене IP (типично для мобильных сетей). Подробнее про эволюцию в контексте веба — в разделе "Эволюция сетевого уровня" и в статье "Эволюция HTTP" раздела "Сеть и интернет"; таблица RFC — в справочнике HTTP.
Открытие https://spirzen.ru в браузере
Разберём типичный сценарий: вы вводите в адресной строке https://spirzen.ru и нажимаете Enter. До первого HTTP-запроса происходит цепочка на нескольких уровнях стека — её можно посмотреть в интерактивном блоке "Сетевой стек" выше на этой странице или в статье Сеть и интернет.
1. DNS. Браузер узнаёт IP-адрес домена spirzen.ru. Сначала проверяются кэш браузера и ОС; при промахе запрос уходит к резолверу (провайдер, 8.8.8.8, 1.1.1.1 или DoH). Резолвер при необходимости обходит Root (где зона .ru), TLD и авторитативные серверы зоны spirzen.ru, получает запись A/AAAA, кэширует ответ и возвращает IP клиенту. До этого момента HTTP-запрос не отправляется. Полная таблица шагов — в DNS — пошаговый резолв.
2. TCP. Устанавливается соединение с сервером на порт 443 (HTTPS).
3. TLS Handshake. До HTTP идёт криптографическое рукопожатие:
Client Hello/Server Hello— версия TLS и набор шифров;- сервер присылает сертификат; браузер проверяет домен и цепочку до CA (часто Let's Encrypt);
- обмен ключами — стороны согласуют общий секрет (часто ECDH); в классических схемах клиент может передать премастер, зашифрованный открытым ключом из сертификата сервера;
- дальше весь HTTP (включая пароли в формах) шифруется симметрично сессионными ключами — см. открытый и закрытый ключ.
В расширении SNI (Server Name Indication) клиент передаёт имя хоста spirzen.ru в открытом виде — так сервер на одном IP выбирает правильный сертификат для виртуального хостинга. Схемы TCP + HTTP и TCP + TLS — HTTPS и TLS — установление соединения.
4. Первый HTTP-запрос. Уже внутри зашифрованного канала браузер отправляет запрос главной страницы. В DevTools (F12 → Network → первый документ → Headers) вы увидите логические поля; в сети между узлами текст заголовков не читается без расшифровки TLS.
Упрощённый вид запроса (как в HTTP/1.1; в HTTP/2 те же поля, но в бинарных кадрах с HPACK-сжатием):
GET / HTTP/1.1
Host: spirzen.ru
User-Agent: Mozilla/5.0 ...
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: ru-RU,ru;q=0.9,en;q=0.8
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
| Поле | Смысл |
|---|---|
GET | получить ресурс без тела запроса |
/ | корень сайта (индексная страница); для https://spirzen.ru/about путь был бы /about |
Host | обязателен в HTTP/1.1: какой виртуальный хост на IP |
User-Agent | браузер и ОС |
Accept / Accept-Encoding | какие форматы и сжатие клиент понимает |
Sec-Fetch-* | контекст навигации (документ, переход по ссылке и т.д.) |
5. HTTP-ответ. Сервер (часто через CDN) возвращает статус, заголовки и тело (HTML). Для spirzen.ru типичны заголовки хостинга на GitHub Pages и кэша Fastly — без учёта cookies в каждом визите:
HTTP/1.1 200 OK
Server: GitHub.com
Content-Type: text/html; charset=utf-8
Content-Length: ...
Last-Modified: ...
ETag: "..."
Cache-Control: max-age=600
Access-Control-Allow-Origin: *
Via: 1.1 varnish
X-Cache: MISS
Vary: Accept-Encoding
| Часть ответа | Назначение |
|---|---|
200 OK | ресурс найден и отдан |
Content-Type | тело — HTML в UTF-8 |
ETag / Last-Modified | условные запросы и кэш (возможен ответ 304 Not Modified) |
Cache-Control / expires | как долго браузер/CDN может не переспрашивать |
Via, X-Cache, X-Served-By | путь через CDN и попадание в кэш |
Vary: Accept-Encoding | разные ответы для gzip/br и без сжатия |
После ответа браузер парсит HTML и инициирует дополнительные запросы (CSS, JS, шрифты, картинки) — часто параллельно по одному TLS-соединению (HTTP/2+).
6. Рендеринг в браузере. Полученный HTML разбирается в DOM (разметка → токены → дерево узлов). Параллельно загружаются таблицы стилей и строится CSSOM. DOM и CSSOM объединяются в Render Tree; затем layout (расчёт размеров и позиций) и paint (вывод пикселей). JavaScript может изменять DOM и CSSOM после загрузки и вызывать повторную отрисовку. Классы статус-кодов в ответе (2xx успех, 3xx редирект, 4xx ошибка клиента, 5xx сбой сервера) — в шпаргалке статусов. Полная схема трёх фаз и конвейер отрисовки — "От URL до пикселей"; семь этапов для веб-приложений — Архитектура веб-приложений.
Проверить актуальные заголовки: DevTools → Network, или в терминале curl -I https://spirzen.ru/ (на Windows — curl.exe).
Пример сложного запроса
Пример сложного HTTP-запроса:
PATCH /api/v2/users/12345/preferences HTTP/2
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.xxxxx
Content-Type: application/json
Accept: application/vnd.mycompany.api.v2+json
Accept-Language: en-US,en;q=0.9,ru;q=0.8
If-Match: "a1b2c3d4"
X-Request-ID: 7c6d3a1b-9f0e-4d2a-bcde-f123456789ab
Cache-Control: no-cache
{
"theme": "dark",
"notifications": {
"email": true,
"sms": false
},
"preferences": {
"language": "en",
"currency": "USD",
"units": "metric"
},
"favorite_items": [101, 102, 105]
}
Давайте разберём.
- Стартовая строка здесь будет такой:
PATCH /api/v2/users/12345/preferences HTTP/2
PATCH - метод, используется для частичного обновления ресурса.
/api/v2/users/12345/preferences — путь к ресурсу на сервере.
HTTP/2 — версия протокола. В отличие от HTTP/1.1, это бинарный протокол с поддержкой мультиплексирования.
- Заголовок здесь будет часть запроса, от Host до Cache-Control.
Host: api.example.com указывает домен, на который отправляется запрос. Особенно важно при использовании виртуального хостинга.
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.xxxxx - это токен авторизации в формате JWT (JSON Web Token). Используется для идентификации пользователя или сервиса.
Content-Type: application/json указывает, что тело запроса содержит данные в формате JSON.
Accept: application/vnd.mycompany.api.v2+json это запрашиваемый формат ответа. Здесь указан кастомный MIME-тип для API версии 2 от компании mycompany.
Accept-Language: en-US,en;q=0.9,ru;q=0.8 это языковые предпочтения клиента. Сервер может выбрать язык ответа в зависимости от доступных вариантов.
If-Match: "a1b2c3d4" это условный заголовок. Сервер выполнит запрос только если ETag ресурса совпадает с этим значением. Используется для оптимистической блокировки (preventing race conditions).
X-Request-ID: 7c6d3a1b-9f0e-4d2a-bcde-f123456789ab это кастомный заголовок, используемый для логгирования и трассировки запроса на стороне сервера.
Cache-Control: no-cache это инструкция клиенту и промежуточным серверам не использовать закэшированный ответ без проверки актуальности.
- Тело запроса здесь будет JSON-объектом, содержащим пользовательские настройки интерфейса (тема), уведомления - включены ли email или SMS, предпочтения (язык, валюта, единицы измерения), список любимых элементов (ID товаров).
Приведенный в примере запрос является сложным, так как здесь используется редкий метод PATCH, версия HTTP/2 (бинарный протокол, мультиплексирование и другие продвинутые возможности), авторизация через Bearer Token, кастомный Accept тип и условный запрос.
Bearer Token — механизм авторизации, при котором клиент предоставляет токен (через OAuth 2.0, JWT или, в простых интеграциях, API-ключ в том же заголовке), который сервер проверяет. При каждом запросе к защищённому API клиент добавляет заголовок Authorization. Сервер проверяет токен и при успехе разрешает доступ.
Синтаксис заголовка одинаковый (Bearer …), а проверка на сервере разная: JWT — подпись и срок exp без обязательного запроса в БД;
API-ключ — поиск в реестре ключей.
Когда что выбирать — в авторизации в интеграционных сценариях и в аутентификации и авторизации.
Кастомные заголовки и типы обычно начинаются с префикса X-… - хотя с 2012 года рекомендуется использовать зарегистрированные заголовки , а не X-*, так как некоторые системы могут игнорировать такие заголовки. Кастомные типы контента (MIME-типы) указываются без X, но, как выше приведено в примере, может указывать на специфический формат (application/vnd.mycompany.api.v2+json - JSON в специальной версии v2 от компании mycompany).
Условные запросы в HTTP представляют собой механизм, позволяющий выполнять запросы только при выполнении определённых условий.
| Заголовок | Назначение |
|---|---|
| If-Match | Выполнить запрос, только если ETag совпадает. |
| If-None-Match | Выполнить запрос, только если ETag НЕ совпадает. |
| If-Modified-Since | Только если ресурс был изменён после указанной даты. |
| If-Range | Используется при частичной загрузке (Range requests). |
Условные запросы могут предотвратить конфликты при параллельном редактировании, экономят трафик (например, не отправляют данные, если клиент уже имеет актуальную версию), позволяют организовать кэширование и частичную синхронизацию. E-Tag - это уникальный идентификатор текущей версии ресурса.
При конфликте версий сервер может ответить 412 Precondition Failed (заголовок If-Match не совпал с текущим ETag) — клиенту нужно перечитать ресурс и повторить обновление.
Идемпотентность на уровне HTTP
Повтор запроса из-за обрыва сети или таймаута — обычная ситуация в интеграциях. Для неидемпотентных операций (часто POST, например "списать оплату") в API добавляют заголовок Idempotency-Key с уникальным значением (UUID), который клиент генерирует один раз на бизнес-операцию:
POST /api/v1/payments HTTP/1.1
Host: api.shop.example
Content-Type: application/json
Idempotency-Key: 7f3c9a2e-4b1d-4c8e-9f0a-1b2c3d4e5f6a
{"orderId": "ord-42", "amount": 1500.00, "currency": "RUB"}
Сервер запоминает пару "ключ → результат" на ограниченное время — повтор с тем же ключом не создаёт второй платёж, а возвращает тот же ответ, что и при первом успешном вызове. Это дополняет идемпотентность методов PUT/DELETE и снижает риск дублей при retry.
Структура HTTP-ответа
HTTP-ответ содержит тоже три составные части - статус-строка, заголовки и тело ответа.
Статус-строка содержит версию протокола, статусный код и фразу (например, 200 OK). К примеру:
HTTP/2 200 OK
Заголовки содержат метаданные ответа.
Тело ответа содержит фактические данные, например, HTML-страница или данные в JSON.
Пример сложного ответа от сервера:
HTTP/2 200 OK
Content-Type: application/vnd.mycompany.api.v2+json
Content-Language: en-US
ETag: "z9y8x7w6"
X-Request-ID: 7c6d3a1b-9f0e-4d2a-bcde-f123456789ab
Cache-Control: no-store
Vary: Accept-Encoding, Accept-Language
Server: MyCompany-API-Gateway
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
{
"status": "success",
"message": "Preferences updated successfully",
"data": {
"user_id": 12345,
"theme": "dark",
"notifications": {
"email": true,
"sms": false
},
"preferences": {
"language": "en",
"currency": "USD",
"units": "metric"
},
"favorite_items": [101, 102, 105],
"updated_at": "2025-04-05T14:30:00Z"
},
"meta": {
"version": "v2",
"server_time": "2025-04-05T14:30:00Z",
"request_id": "7c6d3a1b-9f0e-4d2a-bcde-f123456789ab"
}
}
Здесь в статус-строке указана версия протокола HTTP/2, код успешного выполнения запроса (200) и ОК - фраза, описывающая результат. В данном случае сервер успешно обработал PATCH-запрос и обновил часть данных пользователя.
Content-Type указывает, что формат данных в теле ответа: application/vnd.mycompany.api.v2+json — специальная версия API компании. Content-Language говорит, что язык содержимого en-US.
ETag это специальный тег, который является уникальным идентификатором текущей версии ресурса. Используется для условных запросов (If-Match, If-None-Match).
X-Request-ID имеет тот же ID, что был отправлен клиентом — используется для логгирования и трассировки.
Cache-Control: no-store говорит о том, что сервер запрещает сохранять этот ответ в кэше.
Vary говорит прокси-серверам, какие заголовки влияют на выбор правильного ответа. Здесь учитываются Accept-Encoding и Accept-Language. Server содержит информацию о сервере.
Strict-Transport-Security обязывает браузер использовать HTTPS, защищая от downgrade-атак.
X-Content-Type-Options: nosniff запрещает браузеру пытаться угадать MIME-тип.
X-Frame-Options: DENY защищает от clickjacking-атак, запрещая отображать страницу в <iframe>. Мы же помним, что такое iframe?
С телом ответа проще — тут JSON с полями вроде status, message, data (полезная нагрузка) и meta (служебная информация). Имена ключей задаёт контракт API; в проде почти всегда используют латиницу (data, items, error), чтобы клиенты на любых языках обращались к полям одинаково.
HTTP-заголовки
Давайте рассмотрим HTTP-заголовки.
- Общие заголовки (General Headers). Заголовки, которые относятся к всему сообщению, но не связаны ни с запросом, ни с ответом напрямую.
| Заголовок | Описание |
|---|---|
| Cache-Control | Управление кэшированием |
| Connection | Управление сетевым соединением (keep-alive, close) |
| Date | Дата и время создания сообщения |
| Pragma | Совместимость с устаревшими кэшами |
| Trailer | Указывает, какие заголовки будут отправлены после тела сообщения |
| Transfer-Encoding | Способ кодирования передачи тела сообщения (например, chunked) |
| Upgrade | Предложение переключиться на другую версию протокола |
| Via | Используется прокси для указания пути |
| Warning | Информация о проблемах при обработке сообщения |
- Заголовки запроса (Request Headers). Передаются клиентом (браузером) серверу и содержат информацию о самом запросе, клиенте или желаемом ответе.
| Заголовок | Описание |
|---|---|
| Accept | Какие типы контента клиент может обработать |
| Accept-Charset | Поддерживаемые клиентом кодировки |
| Accept-Encoding | Поддерживаемые методы сжатия (gzip, deflate) |
| Accept-Language | Языковые предпочтения клиента |
| Authorization | Данные аутентификации |
| Cookie | Клиентские cookies |
| Expect | Ожидание определённого ответа от сервера |
| From | Email пользователя (редко используется) |
| Host | Имя хоста (обязательный заголовок в HTTP/1.1) |
| If-Match, If-None-Match | Условные запросы |
| If-Modified-Since | Проверка изменения ресурса |
| Max-Forwards | Ограничение числа прыжков через прокси |
| Proxy-Authorization | Авторизация перед прокси |
| Range | Запрос части ресурса |
| Referer | Откуда был сделан запрос |
| TE | Какие расширения передачи поддерживает клиент |
| User-Agent | Информация о браузере и ОС |
- Заголовки ответа (Response Headers). Устанавливаются сервером и содержат информацию о результате выполнения запроса.
| Заголовок | Описание |
|---|---|
| Accept-Ranges | Поддерживаемые диапазоны (например, bytes) |
| Age | Возраст ответа (сколько секунд прошло с момента его генерации) |
| Content-Type | Формат данных в теле ответа. |
| Content-Language | Язык содержимого. |
| ETag | Уникальный идентификатор версии ресурса. Используется для условных запросов (If-Match, If-None-Match). |
| Location | Адрес нового ресурса (часто в ответах 3xx) |
| Proxy-Authenticate | Метод аутентификации перед прокси |
| Retry-After | Когда клиент может повторить запрос |
| Server | Информация о сервере или шлюзе, который обработал запрос. |
| Set-Cookie | Установка cookie на стороне клиента |
| Strict-Transport-Security | Обязывает браузер использовать HTTPS, защищая от downgrade-атак. |
| WWW-Authenticate | Требование авторизации |
| Vary | Какие заголовки влияют на выбор закэшированной версии ответа. Здесь учитываются Accept-Encoding и Accept-Language. |
- Заголовки сущности (Entity Headers). Описывают тело сообщения (его тип, размер, кодировку и т. д.).
| Заголовок | Описание |
|---|---|
| Allow | Поддерживаемые методы |
| Content-Encoding | Способ кодирования тела (gzip, compress) |
| Content-Language | Язык содержимого |
| Content-Length | Размер тела сообщения в байтах |
| Content-Location | Альтернативное расположение ресурса |
| Content-MD5 | Контрольная сумма тела (устарел) |
| Content-Range | Диапазон передаваемых данных |
| Content-Type | MIME-тип тела сообщения |
| Content-Disposition | Как браузер должен обрабатывать содержимое (например, inline отобразит в браузере, а attachment предложит сохранить) |
| Expires | Дата истечения срока действия кэша |
| Last-Modified | Дата последнего изменения ресурса |
Content-Type состоит из типа (type) и подтипа (subtype), разделённых косой чертой (type/subtype). Их называют MIME-типы (Multipurpose Internet Mail Extensions), это типы данных, которые могут быть переданы через сеть.
К примеру - text/plain, image/jpeg, application/json. Иногда добавляются парамтеры, например, charset=utf-8, boundary=something_unique.
Есть чит-лист с MIME-типами - https://cheatsheets.zip/mime
Можно ли добавить в HTTP-заголовки ещё больше информации?
Да. Списки выше — не полный перечень всего, что реально ходит по сети. Но важно понимать кто добавляет заголовок и на каком уровне живёт информация.
Что браузер часто добавляет сверх "минимального" примера
| Заголовок | Зачем |
|---|---|
Accept-Language | предпочитаемые языки интерфейса |
Cookie | ранее сохранённые куки сайта |
Referer | откуда перешли (если переход не "прямой") |
DNT | запрос не отслеживать (если включено в настройках) |
Priority | приоритет загрузки (HTTP/2+) |
Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform | Client Hints — сведения о браузере и платформе |
If-None-Match / If-Modified-Since | условный запрос, если страница уже в кэше |
Что может добавить сервер, CDN или API
| Заголовок | Зачем |
|---|---|
Set-Cookie | сессия, настройки, идентификаторы |
Strict-Transport-Security | принудительный HTTPS в будущем |
Content-Security-Policy | откуда можно грузить скрипты и стили |
X-Frame-Options / frame-ancestors | защита от встраивания в чужой iframe |
Location | URL при редиректе (301/302) |
Content-Encoding: br | сжатое тело ответа |
Server-Timing | метрики обработки на сервере |
X-Request-ID | трассировка в логах (часто на API) |
Retry-After, X-RateLimit-* | лимиты и пауза при перегрузке |
Кастомные заголовки
Приложение или прокси могут передавать свои поля, например X-Request-ID, X-Forwarded-For (IP клиента за nginx), X-My-App-Version. Исторически использовали префикс X-; для новых API предпочтительнее зарегистрированные имена из спецификаций, а не произвольные X-*, которые промежуточные узлы иногда отбрасывают.
Что в HTTP-заголовки не переносится автоматически
| Данные | Где они на самом деле |
|---|---|
| IP после DNS | уровень IP |
имя spirzen.ru для выбора сертификата | SNI в TLS ClientHello |
| сертификат, cipher suite | TLS handshake |
| бинарные кадры HTTP/2 | транспорт HTTP/2; смысл полей тот же, формат другой |
Дублировать в HTTP, например, "версию шифра TLS" имеет смысл только если сервер сам напишет это в отладочном заголовке — в обычной веб-навигации так не делают.
Ограничения при "расширении" заголовков
- Размер — суммарный объём заголовков запроса часто ограничен порядка 8–32 КБ (зависит от nginx, CDN, балансировщика). Большие JWT в
Authorizationили длинныеCookieупираются в лимит. - Приватность — лишние поля (
User-Agent, Client Hints,Referer) увеличивают отпечаток браузера; современные браузеры часть данных урезают. - Кэш — каждый заголовок в
Varyозначает отдельные варианты ответа в CDN → сложнее кэширование. - Стандарт — неизвестные имена сервер может игнорировать; стандартные поля должны соответствовать RFC.
Итог: при открытии https://spirzen.ru браузер уже шлёт больше, чем короткий учебный пример; ответ сервера/CDN тоже богаче (кэш, ETag, Via). Добавить ещё метаданные можно, но осмысленно — там, где это нужно для API, безопасности, кэша или трассировки, а не "для полноты". Увидеть фактический набор: DevTools → Network или блок Анализатор запросов выше на этой странице.
Content-Type
Основные категории Content-Type:
- text/ — текстовые данные, простой текст:
| Тип | Описание |
|---|---|
| text/plain | Обычный текст без форматирования |
| text/html | HTML-документ |
| text/css | CSS-стили |
| text/javascript | JavaScript-код (устаревший, сейчас чаще используется application/javascript) |
| text/csv | Таблицы в формате CSV |
- image/ — графические изображения:
| Тип | Описание |
|---|---|
| image/jpeg | Фотографии, формат JPEG |
| image/png | Изображения с прозрачностью, PNG |
| image/gif | Анимированные/статичные GIF |
| image/webp | Современный формат от Google |
| image/svg+xml | Векторная графика в формате SVG |
- audio/ и video/ — медиафайлы
| Тип | Описание |
|---|---|
| audio/mpeg | MP3-файл |
| audio/ogg | OGG-формат аудио |
| video/mp4 | Видео в формате MP4 |
| video/webm | Видео WebM, поддерживается в браузерах |
- application/ — прикладные данные, это самый обширный тип, используется для файлов, данных в определённом формате, двоичных данных и т. д.:
| Тип | Описание |
|---|---|
| application/json | JSON-данные |
| application/xml | XML-данные |
| application/javascript | JavaScript документ |
| application/soap+xml | SOAP |
| application/xhtml+xml | XHTML документ |
| application/pdf | PDF-документ |
| application/msword | Документ Word (.doc) |
| application/vnd.openxmlformats-officedocument.wordprocessingml.document | Word .docx |
| application/octet-stream | Бинарные данные (универсальный "неизвестный" тип) |
| application/x-www-form-urlencoded | Данные формы, отправленной через POST |
| application/zip | ZIP-архив |
| application/gzip | GZIP-архив |
- multipart/ — составные сообщения, используемые, когда в одном сообщении передаётся несколько частей. Например, при загрузке файла через форму. Виды:
| Тип | Описание |
|---|---|
| multipart/form-data | Используется при загрузке файлов через HTML-формы |
| multipart/byteranges | Используется для передачи диапазонов байтов (например, при паузе в загрузке) |
- message/ — сообщения:
| Тип | Описание |
|---|---|
| message/rfc822 | Сообщение электронной почты в формате RFC 822 |
| message/http | Сообщение HTTP внутри другого HTTP-сообщения |
- model/ — моделирование: | Тип | Описание | | :--- | :---: | |model/stl |STL-файлы 3D-моделей |model/gltf+json |Формат GLTF для 3D-графики
Content-Type отсутствует, если данные передаются в URL. Такое можно наблюдать в запросах с методом GET. К примеру, здесь нет Content-Type, так как нет данных в теле:
GET /search?q=hello HTTP/1.1
Host: example.com
Основной способ отправки данных - метод POST:
POST /api/login HTTP/1.1
Content-Type: application/json
Content-Length: 45
{"username":"john","password":"secret"}
Здесь указывается метод POST, URL api/login, протокол HTTP/1.1, тип контента же представляет собой JSON-объект.
Он помогает браузеру или серверу понять, как интерпретировать данные, которые были переданы.
HTTP-методы
HTTP-методы определяют тип действия, которое клиент хочет выполнить на сервере. В REST API и вебе чаще всего встречаются девять методов — их удобно держать под рукой при проектировании API, отладке в DevTools и написании интеграционных тестов. Как метод сочетается с URL, версией, фильтрами и пагинацией — в разборе REST-запроса; чек-лист проектирования RESTful API (идемпотентность, коды, batch) — восемь принципов; теория batch/bulk/chunk — Пакетная работа с данными.
| Метод | Назначение | Типичный код ответа |
|---|---|---|
GET | Получить один ресурс или список | 200 OK |
POST | Создать новый ресурс или выполнить действие | 201 Created |
PUT | Полностью заменить существующий ресурс | 200 OK |
PATCH | Частично изменить ресурс | 200 OK |
DELETE | Удалить ресурс | 200 OK, 204 No Content |
HEAD | Как GET, но без тела ответа | 200 OK |
OPTIONS | Узнать, какие методы поддерживает URI | 200 OK + заголовок Allow |
CONNECT | Установить двусторонний туннель через прокси (HTTPS) | 200 OK |
TRACE | Диагностика — эхо запроса для отладки пути | 200 OK |
Свойства методов (безопасность, идемпотентность, кэширование) и полная таблица по RFC — в справочнике HTTP.
POST, PUT и PATCH все отправляют тело запроса, но семантика разная. Запомнить проще так:
- POST — «создай новое» или «выполни действие»; URL обычно указывает на коллекцию (
/users), а не на конкретный id. Два одинаковых POST подряд часто дают два новых объекта. - PUT — «вот полная новая версия объекта»; URL с id (
/users/123). Непереданные в теле поля часто сбрасываются — как если бы старую запись удалили и вставили новую с тем же ключом (аналогDELETE + INSERT). - PATCH — «измени только эти поля»; остальные остаются. Удобен для форм «отредактировать профиль», когда клиент не хочет слать весь объект (аналог
UPDATEодного столбца).
На практике чаще путают PUT и PATCH: для частичного обновления берите PATCH; PUT оставьте для полной замены или создания по заранее известному id (PUT /users/123, если записи ещё нет). POST не всегда про создание — POST /login или POST /orders/5/cancel запускают действие, а не добавляют ресурс в коллекцию.
POST, PUT и PATCH — в чём разница
Три метода меняют данные на сервере. Мнемоника: POST — новый объект, PUT — новая версия целиком, PATCH — правка по месту.
POST | PUT | PATCH | |
|---|---|---|---|
| Образно | «Добавь новую запись» | «Замени объект целиком» (как DELETE + INSERT, но тот же id) | «Подправь только то, что прислали» |
| Аналог CRUD | Create | Update (полная замена) | Update (частичный) |
| Типичный URL | /users (коллекция) | /users/123 (конкретный ресурс) | /users/123 |
| Тело запроса | данные нового объекта (id часто не нужен) | весь объект — полный снимок | только изменяемые поля |
| Поля, которых нет в теле | не применимо (создаётся новый) | обычно сбрасываются или становятся значением по умолчанию | остаются как были |
| Идемпотентность | обычно нет (два POST → две записи) | да (повтор даёт тот же результат) | не гарантирована |
| Типичный ответ | 201 Created + Location | 200 OK или 204 No Content | 200 OK |
Один объект — три сценария. Был пользователь:
{"id": 123, "name": "Аня", "email": "a@x.ru", "role": "user"}
| Запрос | Тело | Что получится на сервере |
|---|---|---|
PATCH /users/123 | {"email": "new@x.ru"} | сменится только email; name и role не тронуты |
PUT /users/123 | {"name": "Аня", "email": "new@x.ru"} | полная замена: поле role пропало из тела → может исчезнуть |
POST /users | {"name": "Боб", "email": "b@x.ru"} | новый пользователь с новым id (например, 456) |
Ниже — разбор каждого метода с примерами HTTP-сообщений.
GET — чтение данных
Получение одного объекта или коллекции. Сервер не должен менять состояние при GET.
GET /v1/products/iphone HTTP/1.1
Host: api.example.com
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
{"name": "iPhone 14", "description": "Смартфон Apple"}
Для HTML-страниц тело ответа будет разметкой (<h1>, <p> и т.д.), для API — JSON или XML.
POST — создание
Отправка данных на сервер для создания новой записи или запуска операции (оплата, отправка формы).
POST /v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
{"firstname": "bob", "lastname": "smith", "email": "bob@example.com"}
HTTP/1.1 201 Created
Location: /v1/users/456
Content-Type: application/json
{"id": 456, "firstname": "bob", "lastname": "smith", "email": "bob@example.com"}
PUT — полная замена
Обновление ресурса по известному идентификатору. Тело запроса заменяет ресурс целиком.
PUT /v1/users/123 HTTP/1.1
Host: api.example.com
Content-Type: application/json
{"name": "bob", "email": "bob@example.com"}
HTTP/1.1 200 OK
PATCH — частичное обновление
Меняются только переданные поля — в отличие от PUT, который перезаписывает весь объект.
PATCH /v1/users/123 HTTP/1.1
Host: api.example.com
Content-Type: application/json
{"email": "bob@example.com"}
HTTP/1.1 200 OK
DELETE — удаление
DELETE /v1/users/123 HTTP/1.1
Host: api.example.com
HTTP/1.1 204 No Content
При успехе сервер может вернуть 200 OK с телом или 204 No Content без тела.
HEAD — метаданные без тела
Семантика как у GET, но в ответе только заголовки. Удобно проверить существование ресурса, размер или дату изменения без загрузки содержимого.
HEAD /v1/products/iphone HTTP/1.1
Host: api.example.com
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 58
Last-Modified: Wed, 21 Oct 2025 07:28:00 GMT
OPTIONS — поддерживаемые методы
Клиент (часто браузер при CORS) спрашивает, какие операции разрешены для URI.
OPTIONS /v1/users HTTP/1.1
Host: api.example.com
HTTP/1.1 200 OK
Allow: GET, POST, DELETE, HEAD, OPTIONS
Access-Control-Allow-Methods: GET, POST, DELETE, HEAD, OPTIONS
CONNECT — туннель через прокси
Используется прокси-клиентами для установки TCP-туннеля, чаще всего к порту 443 (HTTPS). Обычный прикладной код API этот метод не вызывает.
CONNECT api.example.com:443 HTTP/1.1
Host: api.example.com:443
Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==
HTTP/1.1 200 Connection Established
TRACE — диагностика пути запроса
Эхо-запрос: сервер возвращает полученные заголовки. Применяется для отладки цепочки прокси. На продакшене часто отключён из соображений безопасности.
TRACE /index.html HTTP/1.1
Host: example.com
HTTP/1.1 200 OK
Content-Type: message/http
TRACE /index.html HTTP/1.1
Host: example.com
Via: 1.1 proxy.example.com
Классические операции с данными (Create, Read, Update, Delete) в REST API обычно сопоставляют с POST, GET, PUT/PATCH и DELETE. Чем отличаются три «пишущих» метода — в таблице POST / PUT / PATCH выше. Подробнее о семантике в контексте REST — в главе про Postman и API.
HTTP-статусы
HTTP-статусы указывают на результат выполнения запроса. Первая цифра кода задаёт класс — 1xx — промежуточный ответ, 2xx — успех, 3xx — перенаправление, 4xx — ошибка клиента или запроса, 5xx — ошибка сервера.
| Класс | Частые коды | Смысл |
|---|---|---|
| 1xx | 100, 101, 103 | Запрос принят, ответ ещё формируется (103 Early Hints — подсказки для предзагрузки). |
| 2xx | 200, 201, 204 | Успех: данные в теле (200), ресурс создан (201), успех без тела (204). |
| 3xx | 301, 302, 304, 307, 308 | Редирект или "не менялся" (304 + кэш). 307/308 сохраняют метод запроса. |
| 4xx | 400, 401, 403, 404, 409, 422, 429 | Ошибка запроса, прав или лимита; клиент или контракт API. |
| 5xx | 500, 502, 503, 504 | Сбой сервера или цепочки прокси → backend. |
Полная шпаргалка (включая 418, WebDAV, 451, коды Nginx/CDN) и разбор по RFC — в справочнике HTTP, статус-коды. Для проектирования REST и таблицы retry по кодам — проектирование API.
Смежные материалы
- Справочник HTTP — шпаргалка по статус-кодам
- API — интерфейсы
- Проектирование API и интеграций — коды ошибок и таблица retry в сквозном примере
- Модель Ричардсона
- Практикум — API-тестер на Groovy и JMeter — ручной HTTP-клиент, embedded JMeter, разбор запроса/ответа
- Маршрут по главам API