HTTP, или Hypertext Transfer Protocol, — прикладной протокол обмена данными между клиентом и сервером. Он лежит в основе работы веб-сайтов, REST API, мобильных приложений, микросервисов и множества интернет-сервисов.
Когда пользователь открывает страницу в браузере, клиент отправляет HTTP Request серверу. Сервер обрабатывает запрос и возвращает HTTP Response с HTML, JSON, изображением, файлом или другим содержимым.
HTTP определяет формат запроса и ответа, методы операций, заголовки, коды состояния и правила передачи данных между приложениями.
HTTP отвечает не за физическую доставку пакетов по сети, а за понятный приложениям формат запросов и ответов поверх транспортной инфраструктуры.
Что такое HTTP простыми словами
HTTP можно представить как язык общения браузера и веб-сервера.
Клиент говорит: дай мне страницу /products. Сервер отвечает: запрос выполнен успешно, вот данные.
Client → HTTP Request → Server Client ← HTTP Response ← Server
Такой механизм используется не только браузерами. Backend может обращаться по HTTP к другому Backend, мобильное приложение — к API, а Webhook — отправлять уведомление во внешнюю систему.
Расшифровка HTTP
HTTP означает Hypertext Transfer Protocol — протокол передачи гипертекста.
Исторически он создавался прежде всего для передачи HTML-документов, но современный HTTP используется для практически любых типов данных.
Через него передают JSON, XML, изображения, видео, CSS, JavaScript, архивы и бинарные файлы.
Как работает HTTP
- Клиент определяет адрес сервера.
- При необходимости DNS преобразует доменное имя в IP.
- Устанавливается сетевое соединение.
- Клиент отправляет HTTP Request.
- Server обрабатывает запрос.
- Server возвращает HTTP Response.
- Клиент интерпретирует полученные данные.
HTTP Request
HTTP Request — сообщение от клиента серверу.
Оно содержит Method, путь к ресурсу, Headers и при необходимости Body.
GET /products/42 HTTP/1.1 Host: example.com Accept: application/json
В этом примере клиент запрашивает товар с идентификатором 42.
HTTP Response
HTTP Response — ответ сервера на запрос клиента.
Он содержит Status Code, Headers и обычно Response Body.
HTTP/1.1 200 OK
Content-Type: application/json
{"id":42,"name":"Ноутбук"}Код 200 сообщает об успешной обработке, а Content-Type показывает формат данных.
Структура HTTP Request
| Часть | Назначение |
|---|---|
| Method | Определяет тип действия |
| URL или Path | Указывает ресурс |
| Headers | Передают служебные параметры |
| Body | Содержит отправляемые данные |
HTTP Methods
Метод HTTP описывает намерение клиента.
| Method | Типичный смысл |
|---|---|
| GET | Получить данные |
| POST | Создать ресурс или выполнить действие |
| PUT | Заменить или обновить ресурс |
| PATCH | Частично изменить ресурс |
| DELETE | Удалить ресурс |
| HEAD | Получить Headers без обычного Body |
| OPTIONS | Получить информацию о поддерживаемых возможностях |
GET
GET используется для получения ресурса.
GET /users/125
Запрос не должен изменять бизнес-состояние ресурса только из-за самого чтения.
GET особенно часто применяется для страниц, API-выборок и загрузки статических файлов.
POST
POST обычно используют для создания ресурса или выполнения действия.
POST /orders
Request Body может содержать новый заказ в JSON.
Повтор одного POST не всегда безопасен, поскольку сервер может создать еще один ресурс или повторно выполнить операцию.
PUT
PUT обычно означает создание или полную замену представления ресурса по известному адресу.
Конкретный API Contract определяет точную семантику.
В правильно спроектированной модели одинаковый повторный PUT обычно должен приводить к тому же итоговому состоянию.
PATCH
PATCH используется для частичного изменения ресурса.
Например, приложение хочет изменить только status заказа, не передавая остальные поля.
Формат частичного изменения определяется API.
DELETE
DELETE сообщает о необходимости удалить ресурс или перевести его в состояние, эквивалентное удалению в терминах API.
Фактически Backend может использовать физическое удаление или Soft Delete.
HEAD
HEAD похож на GET, но клиент запрашивает только Headers без обычного Response Body.
Это может использоваться для проверки метаданных ресурса или доступности.
OPTIONS
OPTIONS позволяет запросить информацию о возможностях взаимодействия с ресурсом.
Он также играет важную роль в CORS Preflight Requests браузеров.
Что такое URL
URL определяет адрес ресурса.
https://api.example.com/products/42?currency=EUR
Он может включать Scheme, Host, Port, Path, Query Parameters и другие части.
Scheme
Scheme показывает используемую схему доступа.
http:// https://
HTTPS означает HTTP с защищенным транспортом через TLS.
Host
Host определяет имя сервера.
api.example.com
DNS обычно преобразует это имя в IPv4 или IPv6 Address.
Path
Path обозначает конкретный ресурс или Endpoint.
/products/42
Backend Router сопоставляет этот путь с соответствующим обработчиком.
Query Parameters
Query Parameters передаются после символа вопроса.
/products?category=laptop&page=2
Они часто используются для фильтрации, поиска, сортировки и Pagination.
HTTP Headers
Headers передают метаданные запроса или ответа.
Например:
Content-Type: application/json Authorization: Bearer token Accept: application/json
Headers влияют на Authentication, Cache, форматы данных, Compression и другие аспекты взаимодействия.
Content-Type
Content-Type сообщает формат Body.
Content-Type: application/json
Это означает, что тело сообщения содержит JSON.
Для HTML используется text/html, а для других форматов — соответствующие Media Types.
Accept
Accept показывает, какой формат ответа предпочитает клиент.
Accept: application/json
Server может использовать этот Header для Content Negotiation.
Например, один Endpoint теоретически может возвращать HTML одному клиенту и JSON другому при наличии такой логики.
Content Negotiation
Content Negotiation позволяет клиенту и серверу согласовать подходящее представление ресурса.
Для этого могут использоваться Headers Accept, Accept-Language и другие механизмы.
Server не обязан поддерживать все запрашиваемые варианты.
Authorization Header
Authorization используется для передачи данных, связанных с аутентифицированным доступом.
Authorization: Bearer ey...
Так API может получать Access Token.
Передавать секретные Credentials следует только через защищенное соединение HTTPS.
HTTP Body
Body содержит основное содержимое сообщения.
Например, POST Request может передавать JSON:
{
"customer_id": 125,
"product_id": 42,
"quantity": 1
}GET обычно используется без Request Body, тогда как POST, PUT и PATCH часто содержат данные.
HTTP Status Codes
Status Code показывает результат обработки запроса.
| Диапазон | Значение |
|---|---|
| 1xx | Информационные ответы |
| 2xx | Успешное выполнение |
| 3xx | Перенаправление |
| 4xx | Ошибка на стороне запроса клиента |
| 5xx | Ошибка обработки на стороне сервера |
200 OK
200 означает успешную обработку запроса.
Например, GET возвращает найденный ресурс.
201 Created
201 обычно используют после успешного создания нового ресурса.
Например, POST /orders создал новый заказ.
204 No Content
204 означает успешное выполнение без Response Body.
Такой ответ может использоваться после удаления или обновления, когда возвращать данные не требуется.
301 и 302
Коды семейства 3xx используются для перенаправления клиента.
Server передает новое местоположение через соответствующий Header, а клиент может выполнить новый Request.
304 Not Modified
304 используется в механизмах HTTP Cache.
Server сообщает, что сохраненная клиентом версия ресурса все еще актуальна и повторно передавать Body не нужно.
400 Bad Request
400 означает, что запрос некорректен на уровне, который Server не может нормально обработать.
Например, JSON имеет неправильную структуру или отсутствует обязательный параметр.
401 Unauthorized
401 обычно означает, что запрос требует корректной Authentication.
Название кода исторически может вводить в заблуждение: на практике речь обычно идет именно об отсутствии или проблеме Authentication Credentials.
403 Forbidden
403 означает, что Server понял запрос, но не разрешает выполнить операцию.
Например, пользователь аутентифицирован, но не имеет роли администратора.
404 Not Found
404 означает, что запрашиваемый ресурс не найден или Server не раскрывает его наличие.
Это один из самых известных HTTP Status Codes.
409 Conflict
409 указывает на конфликт с текущим состоянием ресурса.
Например, API не может создать пользователя с уже существующим уникальным email.
422
В некоторых API код 422 используется, когда формат запроса понятен, но данные не проходят прикладную валидацию.
Конкретная модель ошибок должна быть последовательно описана в API Contract.
429 Too Many Requests
429 означает, что клиент превысил разрешенный Rate Limit.
API может попросить повторить запрос позже.
500 Internal Server Error
500 означает внутреннюю ошибку при обработке Request.
Клиенту не следует показывать технический Stack Trace или секретные детали приложения.
502 Bad Gateway
502 часто появляется, когда Proxy или Gateway получил некорректный ответ от upstream-сервиса.
Например, Nginx работает, но Backend завершился или отвечает неправильно.
503 Service Unavailable
503 сообщает, что сервис временно не готов обработать запрос.
Причиной может быть перегрузка, Maintenance или недоступность критичной зависимости.
504 Gateway Timeout
504 означает, что Gateway или Proxy слишком долго ждал ответ от upstream.
Это распространенная ошибка в распределенных системах.
HTTP и TCP/IP
HTTP работает на прикладном уровне поверх сетевого стека.
В классической модели HTTP/1.1 и HTTP/2 обычно используют TCP, а TCP работает поверх IPv4 или IPv6.
HTTP ↓ TCP ↓ IP ↓ Network
HTTP не занимается маршрутизацией IP-пакетов самостоятельно.
HTTP и HTTPS
HTTPS — это HTTP, передаваемый через защищенный TLS-канал.
TLS обеспечивает Encryption, Integrity и проверку подлинности Server через Certificates.
Для внешних веб-сайтов и API HTTPS является стандартным способом безопасного обмена данными.
Почему обычный HTTP небезопасен
Если HTTP передается без TLS, содержимое трафика потенциально можно прочитать или изменить на сетевом пути.
Пароли, Tokens и персональные данные нельзя безопасно передавать через открытый HTTP в недоверенной сети.
TLS Handshake
Перед передачей HTTPS-данных Client и Server выполняют TLS Handshake.
Они согласуют параметры шифрования и проверяют Certificate.
После этого HTTP-сообщения передаются внутри защищенного соединения.
HTTP/1.1
HTTP/1.1 долгое время является широко используемой версией протокола.
Он поддерживает постоянные соединения, Headers, Chunked Transfer и другие механизмы, ставшие основой современной веб-инфраструктуры.
Keep-Alive
Без повторного использования соединения клиенту пришлось бы создавать новый TCP Connection для каждого файла страницы.
Keep-Alive позволяет передавать несколько HTTP Requests через одно соединение.
Это уменьшает количество Handshakes и сетевые накладные расходы.
HTTP/2
HTTP/2 изменяет способ передачи HTTP-сообщений и позволяет эффективнее использовать одно соединение.
Несколько потоков могут передаваться параллельно в рамках одного Connection.
Также применяется более эффективное представление Headers.
Multiplexing
Multiplexing позволяет одному соединению обслуживать несколько независимых HTTP Streams.
Это уменьшает необходимость создавать множество TCP Connections для параллельной загрузки ресурсов.
HTTP/3
HTTP/3 использует транспорт на основе QUIC вместо классической модели HTTP поверх TCP.
QUIC работает поверх UDP и реализует собственные механизмы надежной передачи и управления потоками.
Для прикладного разработчика базовая модель Methods, Headers и Status Codes при этом сохраняется.
HTTP/2 и HTTP/3 не меняют смысл REST API
Backend по-прежнему может использовать GET /users или POST /orders.
Изменяется прежде всего транспорт и эффективность передачи, а не бизнес-семантика Endpoint.
HTTP и REST API
REST API часто использует HTTP как транспорт и применяет Methods, URLs, Headers и Status Codes для работы с ресурсами.
Например:
GET /products POST /orders PATCH /users/125 DELETE /sessions/current
При этом HTTP и REST не являются синонимами. HTTP можно использовать и без REST.
HTTP и GraphQL
GraphQL API также часто работает поверх HTTP.
Вместо большого количества REST Endpoints приложение отправляет GraphQL Query на определенный Endpoint.
Таким образом, HTTP обеспечивает транспорт, а GraphQL задает модель запросов к данным.
HTTP и gRPC
gRPC использует HTTP/2 как часть своей транспортной модели.
Но его сообщения и контракт отличаются от обычного JSON REST API.
Поэтому использование HTTP не делает gRPC обычным REST-сервисом.
HTTP и Webhook
Webhook — HTTP Request, автоматически отправляемый при наступлении события.
Например, платежная система отправляет POST на URL интернет-магазина после успешного платежа.
Получатель должен проверять Authentication или Signature, учитывать Retry и делать обработку идемпотентной.
HTTP и Backend
Backend Server принимает HTTP Requests, выполняет Authentication, Validation и бизнес-логику и формирует HTTP Response.
Framework обычно предоставляет Router, Middleware, Request Object и Response API.
HTTP Router
Router сопоставляет URL и Method с обработчиком.
GET /products → listProducts GET /products/42 → getProduct POST /products → createProduct
Так один Backend обслуживает множество Endpoints.
Middleware
Middleware обрабатывает Request до или после основного Handler.
Через него часто реализуют Authentication, Logging, CORS, Rate Limiting и Trace ID.
HTTP и Frontend
Frontend использует HTTP для загрузки HTML, CSS, JavaScript и данных API.
JavaScript может выполнять Requests через браузерные API без полной перезагрузки страницы.
Это основа SPA и многих современных веб-интерфейсов.
HTTP и AJAX
AJAX — исторически сложившееся название подхода, при котором Browser отправляет HTTP Requests в фоне и обновляет страницу без полной перезагрузки.
Сегодня данные часто передаются в JSON, а не обязательно XML.
HTTP и мобильные приложения
Мобильное приложение обычно взаимодействует с Backend через HTTPS API.
Для Server это обычный HTTP Client, аналогичный браузеру по базовой сетевой модели.
Cookies
Cookie позволяет Server передать небольшое значение Browser, которое затем может отправляться в последующих HTTP Requests.
Cookies широко применяются для Sessions, пользовательских настроек и других браузерных сценариев.
Session Cookie
Server может после входа пользователя создать Session ID и отправить его в Cookie.
Browser автоматически прикладывает Cookie к последующим запросам согласно установленным правилам.
Backend использует идентификатор для поиска Session.
Secure Cookie
Флаг Secure ограничивает передачу Cookie защищенными соединениями.
Для Authentication Cookies это важная настройка.
HttpOnly
HttpOnly ограничивает доступ клиентского JavaScript к Cookie.
Это уменьшает часть рисков кражи Authentication Cookie через определенные XSS-сценарии.
SameSite
SameSite управляет отправкой Cookies в межсайтовых сценариях.
Он играет важную роль в защите от части CSRF-атак.
HTTP и Authentication
HTTP сам по себе не определяет единственный способ аутентификации пользователей.
Приложения могут применять Sessions, Tokens, API Keys, OAuth и другие схемы.
Credentials часто передаются через Headers или Cookies.
Bearer Token
API может принимать Access Token через Authorization Header.
Authorization: Bearer token
Такой Token нужно защищать, поскольку владеющий им клиент потенциально получает соответствующие права.
HTTP Basic Authentication
Basic Authentication передает учетные данные в специальном Header в кодированном виде.
Само кодирование не является Encryption, поэтому такая схема должна использоваться только поверх HTTPS и там, где она подходит по требованиям.
CORS
CORS, или Cross-Origin Resource Sharing, — механизм браузера и HTTP Headers, контролирующий доступ JavaScript одного Origin к ресурсам другого Origin.
Например, Frontend работает на app.example.com, а API — api.example.com.
Server должен вернуть подходящие CORS Headers.
Origin
Origin определяется сочетанием Scheme, Host и Port.
Например:
https://example.com https://api.example.com
имеют разные Origins из-за разных Hosts.
Preflight Request
Перед некоторыми Cross-Origin Requests Browser отправляет OPTIONS Request.
Он проверяет, разрешает ли Server требуемый Method и Headers.
Этот запрос называют CORS Preflight.
HTTP Cache
HTTP имеет встроенные механизмы кэширования.
Browser, CDN и Proxy могут временно сохранять Response и повторно использовать его без обращения к Origin Server.
Это уменьшает Latency и нагрузку.
Cache-Control
Cache-Control определяет правила кэширования.
Например, Server может указать, сколько времени ресурс считается актуальным или разрешено ли хранить его в shared Cache.
ETag
ETag — идентификатор версии представления ресурса.
Client может при повторном Request сообщить известный ETag.
Если ресурс не изменился, Server возвращает 304 вместо полной передачи Body.
Last-Modified
Last-Modified сообщает время последнего изменения ресурса.
Он также может использоваться для условных запросов и экономии трафика.
HTTP и CDN
CDN кэширует HTTP Content на Edge Servers ближе к пользователям.
Статические изображения, JavaScript и другие ресурсы могут отдаваться без обращения к Origin.
Правильные Cache Headers существенно влияют на эффективность CDN.
HTTP Compression
Response можно сжимать перед передачей.
Это уменьшает сетевой трафик, особенно для HTML, JSON, CSS и JavaScript.
Server и Client договариваются о поддерживаемых вариантах через HTTP Headers.
HTTP и Proxy
Proxy находится между Client и Server.
Он может фильтровать, кэшировать или маршрутизировать трафик.
В зависимости от направления различают Forward Proxy и Reverse Proxy.
Reverse Proxy
Reverse Proxy принимает внешние HTTP Requests и передает их Backend Servers.
Например, Nginx может завершать TLS, выполнять Load Balancing и добавлять Headers.
HTTP и Nginx
Nginx часто используется как HTTP Server и Reverse Proxy.
Он может отдавать статические файлы и передавать динамические Requests Backend-приложению.
Forwarded Headers
Если Backend находится за Reverse Proxy, он может видеть IP Proxy вместо реального Client Address.
Для передачи исходной информации используются специальные Headers.
Backend должен доверять им только от известных Proxy, иначе клиент сможет попытаться подделать значения.
HTTP и Load Balancer
Load Balancer распределяет HTTP Requests между несколькими Backend Instances.
Это позволяет масштабировать сервис и переживать отказ отдельных серверов.
Health Checks помогают исключать неисправные экземпляры.
HTTP Health Check
Load Balancer может регулярно отправлять Request:
GET /health
Если Backend возвращает ожидаемый статус, он считается готовым принимать Traffic.
Health Endpoint не должен выполнять слишком тяжелые операции.
HTTP и микросервисы
Microservices часто взаимодействуют через HTTP REST или другие HTTP-based протоколы.
Каждый сетевой Request может завершиться Timeout, поэтому распределенная система должна учитывать частичные сбои.
Timeout
HTTP Client должен иметь ограничение времени ожидания.
Без Timeout один зависший внешний сервис способен надолго занять Threads или Connections Backend.
Обычно отдельно учитывают Connection Timeout и ожидание Response.
Retry
После временной сетевой ошибки Request можно повторить, но не всегда это безопасно.
GET обычно проще повторять, а POST платежа может создать двойной эффект.
Поэтому Retry должен учитывать идемпотентность операции.
Идемпотентность HTTP Methods
Идемпотентная операция при многократном одинаковом выполнении приводит к тому же итоговому состоянию, что и однократное выполнение.
GET, PUT и DELETE по стандартной семантике проектируются как идемпотентные, хотя конкретное приложение может нарушить ожидаемое поведение.
POST в общем случае идемпотентным не считается.
Idempotency Key
Для критичных POST Operations API может принимать уникальный Idempotency Key.
Если клиент повторяет запрос после Timeout, Server определяет, что операция уже выполнялась, и не создает второй бизнес-эффект.
Такой подход часто полезен для платежей и заказов.
HTTP и Rate Limiting
API ограничивает количество Requests одного пользователя, Token или IP за период.
При превышении лимита может возвращаться 429.
Rate Limiting защищает сервис от перегрузки и злоупотреблений.
HTTP и API Gateway
API Gateway принимает внешние HTTP Requests и направляет их нужным внутренним сервисам.
На Gateway могут выполняться Authentication, Rate Limiting, Logging и Routing.
HTTP и Docker
Контейнерное Backend-приложение может слушать HTTP Port внутри Docker Network.
Reverse Proxy или Port Mapping делает сервис доступным снаружи.
Host:8080 → Container:80
Для связи между контейнерами удобнее использовать DNS Name сервиса.
HTTP и Kubernetes
В Kubernetes HTTP-приложения обычно доступны через Service и Ingress или другой Gateway-компонент.
Pods могут меняться, а стабильный сетевой Endpoint остается.
Ingress
Ingress-механизм позволяет маршрутизировать входящие HTTP Requests по Host и Path.
Например:
api.example.com/users → user-service api.example.com/orders → order-service
Так множество сервисов могут использовать общий внешний вход.
HTTP и Service Mesh
Service Mesh может анализировать HTTP Traffic между сервисами и применять Routing, Retry, mTLS и Observability.
При этом само приложение продолжает работать с обычными HTTP Requests.
HTTP и Observability
HTTP является удобной точкой измерения производительности приложения.
Обычно отслеживают Request Rate, Error Rate, Latency и распределение Status Codes.
| Метрика | Назначение |
|---|---|
| Request Rate | Количество HTTP Requests |
| Latency | Время обработки |
| 4xx Rate | Ошибки клиентских запросов |
| 5xx Rate | Серверные ошибки |
| Payload Size | Размер передаваемых данных |
HTTP и OpenTelemetry
OpenTelemetry может создавать Span для входящего и исходящего HTTP Request.
Так Trace показывает путь запроса через API Gateway, Backend, Database и внешние сервисы.
Correlation ID
Correlation ID помогает связать Logs нескольких сервисов с одним HTTP Request.
Идентификатор может передаваться через Header между компонентами.
Access Log
Web Server обычно записывает Method, Path, Status Code, время обработки и другие параметры HTTP Request.
Access Logs помогают искать ошибки и анализировать нагрузку.
При этом следует избегать записи паролей, Tokens и других секретных данных.
HTTP и безопасность
Для безопасной эксплуатации HTTP API необходимо применять несколько уровней защиты.
- использовать HTTPS;
- проверять Authentication и Authorization;
- валидировать Input;
- ограничивать размер Body;
- настраивать Rate Limiting;
- не раскрывать Stack Trace;
- защищать Cookies;
- правильно настраивать CORS.
HTTP и XSS
XSS возникает на уровне веб-приложения, когда недоверенные данные могут выполняться в Browser как Script.
HTTP Headers, Content Security Policy, экранирование вывода и безопасная Frontend-разработка помогают уменьшать риски.
HTTP и CSRF
CSRF связан с ситуацией, когда Browser пользователя отправляет нежелательный авторизованный Request на другой сайт.
Для защиты используются SameSite Cookies, CSRF Tokens и другие механизмы.
HTTP Header Injection
Нельзя без проверки помещать пользовательские данные в HTTP Headers.
Некорректная обработка переводов строк и других специальных символов может привести к уязвимостям.
Размер HTTP Request
Server должен ограничивать максимальный размер Body.
Без ограничений злоумышленник или ошибочный клиент может отправлять огромные Requests и потреблять память, сеть и CPU.
Large File Upload
Для больших файлов полезно применять потоковую загрузку или прямую передачу в Object Storage.
Не всегда разумно полностью загружать многогигабайтный файл в память Backend перед сохранением.
HTTP Streaming
HTTP позволяет передавать Response постепенно, не дожидаясь формирования всего содержимого.
Это полезно для больших файлов, потоковых ответов и некоторых real-time сценариев.
Server-Sent Events
Server-Sent Events позволяет Server отправлять поток событий Browser через долгоживущее HTTP-соединение.
Это удобно для однонаправленных обновлений от сервера к клиенту.
HTTP и WebSocket
WebSocket используется для постоянного двунаправленного взаимодействия Client и Server.
Начальная установка соединения исторически связана с HTTP-механизмами, после чего коммуникация работает по другой модели.
Для обычного Request/Response HTTP часто проще.
HTTP и SEO
HTTP Status Codes имеют важное значение для поисковых систем.
200 сообщает об успешной странице, 301 — о постоянном перенаправлении, 404 — об отсутствии ресурса.
Неправильные коды способны мешать индексации и вводить Crawlers в заблуждение.
Robots и HTTP
Поисковые роботы получают страницы через HTTP так же, как другие Clients.
Server может возвращать различный Content-Type, Cache Headers и Status Codes.
Корректная HTTP-конфигурация является частью технического SEO.
Типичные ошибки при работе с HTTP
- Всегда возвращать 200 даже при ошибке.
- Использовать GET для операций, меняющих бизнес-состояние.
- Не устанавливать Timeout для внешних Requests.
- Повторять неидемпотентный POST без защиты.
- Передавать Tokens через незашифрованный HTTP.
- Неправильно настраивать CORS.
- Кэшировать персональные данные без учета политики Cache.
- Возвращать клиенту внутренний Stack Trace.
- Не ограничивать размер Request Body.
- Игнорировать 4xx и 5xx в мониторинге.
Как спроектировать HTTP API
Шаг 1. Определить ресурсы
Endpoint должен соответствовать понятной сущности или операции.
Шаг 2. Выбрать Method
Используйте GET для чтения, POST для создания или действий, PATCH для частичных изменений и другие методы по понятной семантике.
Шаг 3. Настроить Status Codes
Response должен корректно отражать результат операции.
Шаг 4. Описать JSON Contract
Поля Request и Response должны иметь стабильную структуру.
Шаг 5. Добавить Authentication
Защищенные Endpoints должны проверять личность и права.
Шаг 6. Добавить Timeout и Retry Policy
Сетевые ошибки должны обрабатываться предсказуемо.
Шаг 7. Настроить Observability
Нужно видеть Latency, Status Codes и Trace каждого критичного Request.
Шаг 8. Использовать HTTPS
Внешние API и сайты должны передавать чувствительные данные только по защищенному каналу.
Практический пример
Интернет-магазин предоставляет REST API для оформления заказа.
Frontend отправляет:
POST /orders Content-Type: application/json Authorization: Bearer token
Body содержит customer_id и товары.
API Gateway проверяет Token и Rate Limit, затем направляет Request в Order Service.
Backend валидирует данные, создает заказ в Database и возвращает 201 Created.
Если пользователь повторяет запрос из-за сетевого Timeout, Client передает Idempotency Key, поэтому второй заказ не создается.
Если Token отсутствует, API возвращает 401. Если товар не найден — подходящий 4xx Status. При внутреннем сбое — 5xx без раскрытия Stack Trace.
Nginx завершает TLS и передает HTTP Request Backend. OpenTelemetry связывает внешний Request с SQL Query и последующими вызовами сервисов.
Prometheus отслеживает HTTP Latency и долю 5xx. Благодаря этому команда может увидеть деградацию до массовых жалоб пользователей.
HTTP для бизнеса
HTTP является фундаментом большинства цифровых продуктов. Через него работают сайты, интернет-магазины, личные кабинеты, SaaS, мобильные приложения, интеграции и API партнеров.
Стандартизированная модель Request/Response упрощает интеграцию систем независимо от языка программирования.
При этом качество HTTP API напрямую влияет на надежность бизнеса: неверные Timeout, некорректные Status Codes или отсутствие идемпотентности могут приводить к сбоям, двойным операциям и сложной диагностике.
Когда использовать HTTP
- нужен Web API;
- клиент ожидает Request/Response;
- работает Browser или Mobile Application;
- нужно интегрироваться с внешним сервисом;
- используются REST, GraphQL или Webhook;
- требуется стандартный публичный сетевой интерфейс.
Когда одного HTTP недостаточно
Для длительных асинхронных задач может понадобиться Message Broker.
Для большого потока событий используются Kafka или другие Streaming Platforms.
Для постоянного двунаправленного real-time соединения может подойти WebSocket.
HTTP остается важной частью системы, но не обязан решать все виды межсервисного взаимодействия.
Связанные термины
| Термин | Связь с HTTP |
|---|---|
| HTTPS | HTTP через защищенный TLS-канал |
| TCP/IP | Сетевая основа для классических HTTP-соединений |
| REST API | Часто использует HTTP Methods и Status Codes |
| JSON | Популярный формат HTTP API |
| URL | Определяет адрес ресурса |
| HTTP Header | Передает метаданные Request и Response |
| Cookie | Хранит небольшие браузерные данные |
| CORS | Контролирует Cross-Origin Requests в Browser |
| Nginx | Может работать как HTTP Server и Reverse Proxy |
| CDN | Кэширует и доставляет HTTP Content |
| Webhook | HTTP Request, отправляемый при событии |
| OpenTelemetry | Трассирует HTTP Requests между сервисами |
Краткий итог
HTTP — прикладной протокол, который определяет правила обмена запросами и ответами между клиентом и сервером. Он использует Methods, URLs, Headers, Body и Status Codes и является основой веб-сайтов и большинства современных API.
HTTP может работать через разные поколения транспортной инфраструктуры, а HTTPS добавляет TLS и защищает данные от чтения и изменения на сетевом пути. Современные версии HTTP улучшают эффективность передачи, но сохраняют знакомую прикладную модель запросов и ответов.
Для production важно правильно использовать Status Codes, Cache, Authentication, CORS, Timeout, Retry и идемпотентность. Грамотно спроектированный HTTP-интерфейс делает интеграцию систем предсказуемой, безопасной и удобной для развития.
