HTTP, API, REST, JSON и XML: как приложения обмениваются данными

Применение HTTP для взаимодействия приложений и информационных систем — это основа современной цифровой интеграции. Через HTTP интернет-магазин получает данные о товарах, мобильное приложение отправляет заказ, бухгалтерская система запрашивает сведения о клиенте, а микросервис передаёт соседнему сервису результат расчёта. При этом вокруг одного и того же обмена часто смешивают разные понятия: HTTP, API, REST, JSON и XML. Из-за этого возникают ошибки в проектировании, документации и отладке интеграций.

Главная идея: HTTP определяет, как передать запрос и получить ответ, API описывает доступные операции и правила взаимодействия, REST задаёт архитектурный стиль, а JSON и XML служат форматами представления данных.

Чтобы уверенно разрабатывать и подключать интеграции, важно разделять эти уровни. В статье последовательно разобраны устройство HTTP-взаимодействия, роль клиента и сервера, методы REST API, HTTP-коды, JSON и XML, а также практические сценарии обмена между веб-приложениями, микросервисами и корпоративными информационными системами.

Иерархия знаний по HTTP, API и REST

 

Эта схема показывает, как текущая тема связана с другими материалами о веб-взаимодействии. Сначала полезно понять общие принципы HTTP, затем изучить структуру запроса и ответа, версии протокола, связь с HTTPS и сетевой моделью, а после этого перейти к API, REST, JSON и XML.

HTTP
├── HTTP: что это такое и как работает протокол
├── HTTP-запрос и HTTP-ответ: структура, методы, заголовки и коды
├── Версии HTTP: HTTP/1.0, HTTP/1.1, HTTP/2 и HTTP/3
├── HTTP и HTTPS: разница, безопасность и шифрование
├── HTTP в сетевой модели: TCP/IP, OSI, IP, DNS и порты
├── HTTP-сервер, URL и передача файлов: как работает веб
├── HTTP, API, REST, JSON и XML: как приложения обмениваются данными
└── HTTP: настройка, проверка и отладка

Иерархия важна потому, что интеграция редко ограничивается одним уровнем. Если запрос не дошёл до сервера, проблема может находиться в DNS, маршрутизации или порте. Если запрос дошёл, но сервер вернул ошибку, нужно проверять URL, метод, заголовки, авторизацию и формат тела. Если технически всё работает, но системы неправильно понимают друг друга, причина обычно находится уже в контракте API или структуре данных.

 

HTTP и API — в чём разница

HTTP и API часто упоминают рядом, но это не взаимозаменяемые понятия. api и протокол http находятся на разных уровнях: HTTP является стандартом сетевого обмена запросами и ответами, а API представляет собой набор правил, по которым одна программа обращается к функциям и данным другой программы.

Основная статья: HTTP: что это такое и как работает протокол

Что такое HTTP

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

В HTTP-запросе обычно указываются метод, адрес ресурса, заголовки и, при необходимости, тело. В ответе сервер возвращает код состояния, заголовки и содержимое. Например, код 200 означает успешную обработку, 404 — отсутствие ресурса, а 500 — внутреннюю ошибку сервера.

Элемент HTTP-взаимодействия	Назначение	Пример
Метод	Показывает желаемое действие	GET, POST, PUT, DELETE
URL	Определяет адрес ресурса	/api/products/42
Заголовки	Передают служебные сведения	Accept, Authorization
Тело запроса	Содержит отправляемые данные	JSON с параметрами заказа
Код ответа	Показывает результат обработки	200, 201, 400, 404
Тело ответа	Возвращает результат операции	JSON со списком товаров

Что такое API

API — это программный интерфейс, то есть формализованный способ обращаться к возможностям приложения. API может использовать HTTP, но также может работать через другие механизмы: вызовы функций внутри библиотеки, очереди сообщений, WebSocket, операционные сокеты или специализированные протоколы.

Веб-API обычно описывает:

• какие URL доступны клиенту;
• какие HTTP-методы разрешены;
• какие параметры можно передавать;
• какие заголовки обязательны;
• как выполняется аутентификация;
• какие форматы данных принимаются и возвращаются;
• какие ошибки возможны.

Таким образом, API — это не обязательно конкретный URL и не только набор HTTP-запросов. Это договор между программами. Если одна система обещает принимать запрос создания заказа с определёнными полями, а другая отправляет данные в согласованном формате, обе стороны могут развиваться независимо, сохраняя совместимость.

Как API использует HTTP

Когда API реализовано поверх HTTP, каждая операция выражается через запрос к определённому адресу. Метод и URL указывают, что требуется сделать, заголовки передают контекст, а тело содержит данные. Сервер анализирует запрос согласно правилам API и возвращает ответ.

Приложение магазина
        |
        | POST /api/orders
        | Content-Type: application/json
        | {"product_id":42,"quantity":2}
        v
API магазина
        |
        | проверка товара, цены и остатка
        v
HTTP 201 Created
{"order_id":7815,"status":"created"}

В этом примере протокол http взаимодействие обеспечивает передачу сообщения, а API определяет, что адрес /api/orders предназначен для создания заказа, какие поля обязательны и какой результат должен получить клиент.

Почему API и HTTP нельзя считать одним и тем же

HTTP может использоваться без API. Когда пользователь открывает HTML-страницу, браузер отправляет HTTP-запрос, но это ещё не означает наличие программного API. С другой стороны, API может быть построено не на HTTP: например, библиотека предоставляет API через функции, а брокер сообщений — через публикацию событий.

Полезно представить различие в виде уровней:

Вопрос	HTTP	API
Что описывает?	Передачу запросов и ответов	Доступные возможности системы
Где применяется?	В сетевом взаимодействии	В сетевом, библиотечном и межсервисном обмене
Определяет бизнес-правила?	Нет	Да, на уровне контракта и операций
Определяет формат данных?	Поддерживает указание формата через заголовки	Может требовать JSON, XML или иной формат
Пример	GET с кодом 200	Операция «создать заказ»

Клиент: GET /api/customers/15 HTTP/1.1
Host: crm.example.ru
Accept: application/json

Ответ API: HTTP/1.1 200 OK
Content-Type: application/json

{"id":15,"name":"Анна Петрова","active":true}

Здесь протокол обмена http отвечает за доставку запроса и ответа, а API CRM определяет смысл ресурса клиента, формат объекта и правила доступа к нему.

Как приложения взаимодействуют через HTTP

Типичный обмен можно разобрать по ролям. Одна программа выступает клиентом, другая — API-сервером, а между ними передаются HTTP-запрос и HTTP-ответ. В некоторых системах одна и та же программа может быть клиентом в одном взаимодействии и сервером в другом.

Клиент

Клиент инициирует обмен. Он знает адрес API, формирует запрос, добавляет нужные параметры и анализирует ответ. Клиентом может быть фронтенд интернет-магазина, мобильное приложение, кассовая программа, CRM, интеграционный шлюз или фоновая задача.

Клиент должен уметь корректно обрабатывать не только успешный ответ, но и временные сбои, отказ в доступе, неправильные параметры, превышение лимита запросов и недоступность сервера. Хороший клиент не считает любой ответ с HTTP-соединением успешным: он проверяет код, формат и содержимое ответа.

API-сервер

API-сервер принимает запрос, проверяет его структуру и права доступа, выполняет бизнес-логику, обращается к базе данных или другим системам и формирует ответ. В крупных проектах перед самим приложением могут находиться балансировщик, шлюз API, система авторизации и ограничитель частоты запросов.

Этап на сервере	Что проверяется или выполняется	Возможный результат ошибки
Маршрутизация	Существует ли такой путь и метод	404 или 405
Аутентификация	Передан ли действующий токен	401
Авторизация	Есть ли права на операцию	403
Валидация	Корректны ли поля и типы данных	400 или 422
Бизнес-логика	Можно ли выполнить операцию	409 или 422
Хранение данных	Успешно ли обращение к базе	500 или 503

HTTP-запрос

Основная статья: HTTP-запрос и HTTP-ответ: структура, методы, заголовки и коды

HTTP-запрос состоит из стартовой строки, заголовков, пустой строки и необязательного тела. Стартовая строка сообщает метод, путь и версию протокола. Заголовки описывают тип содержимого, предпочтительный формат ответа, авторизацию, кеширование и другие параметры.

POST /api/payments HTTP/1.1
Host: billing.example.ru
Authorization: Bearer token-123
Content-Type: application/json
Accept: application/json

{"invoice_id":"INV-2025-018","amount":12500,"currency":"RUB"}

В этом запросе тело присутствует, потому что клиент передаёт серверу данные о платеже. Для GET-запроса тело обычно не используется: параметры поиска чаще передаются в строке запроса, например /api/products?category=books&limit=20.

HTTP-ответ

HTTP-ответ сообщает, чем завершилась операция. В нём есть строка состояния, заголовки и, если нужно, тело. Код ответа важен для автоматической обработки: приложение может по-разному реагировать на успешное создание объекта, временную недоступность сервиса и ошибку авторизации.

Приложение
   ↓
HTTP-запрос
   ↓
API
   ↓
проверка и обработка
   ↓
HTTP-ответ
   ↓
Приложение получает результат

Группа кодов	Диапазон	Смысл
Информационные	100–199	Промежуточная информация
Успешные	200–299	Запрос обработан
Перенаправления	300–399	Нужно обратиться по другому адресу или использовать кеш
Ошибки клиента	400–499	Проблема в запросе или правах клиента
Ошибки сервера	500–599	Сбой на стороне сервера или зависимости

REST и HTTP

REST часто называют «протоколом», но это неточно. REST — архитектурный стиль, то есть набор принципов организации распределённых систем. HTTP хорошо подходит для реализации REST-подхода, однако REST не заменяет HTTP и не является транспортным протоколом.

Выражение rest api протокол http допустимо понимать только как «REST API, реализованное с использованием HTTP». Сам REST протоколом не становится.

Что такое REST

REST расшифровывается как Representational State Transfer — «передача представления состояния». Архитектурный стиль предлагает рассматривать данные как ресурсы, обращаться к ним через адреса и использовать понятные правила взаимодействия.

К основным принципам REST обычно относят:

• разделение клиента и сервера — интерфейс и серверная логика развиваются независимо;
• отсутствие состояния на сервере между запросами — каждый запрос содержит необходимый контекст;
• единый интерфейс — операции и структура ресурсов подчиняются согласованным правилам;
• кешируемость — ответ может разрешать или запрещать сохранение результата;
• многоуровневая архитектура — клиент может не знать, общается ли он с конечным сервером или шлюзом;
• представление ресурса — один и тот же ресурс может быть представлен JSON, XML или другим форматом.

В реальной документации под REST API часто понимают HTTP API, которое использует ресурсы, стандартные методы и понятные коды ответов. При этом конкретный интерфейс может соответствовать REST-принципам в большей или меньшей степени: слово REST в названии само по себе ничего не гарантирует.

REST API

REST API организует доступ к сущностям приложения как к ресурсам. Например, клиентами, статьями, заказами и платежами могут быть отдельные коллекции ресурсов. URL обозначает ресурс, HTTP-метод — действие, а тело запроса или ответа — представление данных.

GET /api/articles/123 HTTP/1.1
Host: content.example.ru
Accept: application/json

В данном случае HTTP определяет способ передачи запроса: стартовую строку, заголовки, соединение и ответ. REST задаёт архитектурные принципы организации API: статья является ресурсом, у неё есть адрес, а GET используется для получения представления без изменения состояния.

HTTP-методы в REST API

Методы позволяют выразить намерение клиента. На практике сервер может вводить собственные ограничения, но общая семантика методов помогает разработчикам быстро понимать назначение операции.

GET

GET используется для получения ресурса или коллекции ресурсов. Запрос обычно не должен изменять данные. Его можно кешировать, повторять и использовать для чтения списка, карточки товара или статуса заказа.

GET /api/products/42 HTTP/1.1
Host: shop.example.ru
Accept: application/json

POST

POST применяется для передачи данных на обработку. Частый сценарий — создание нового ресурса, но POST может запускать расчёт, поиск со сложными параметрами или другую операцию, не сводимую к простому чтению.

POST /api/orders HTTP/1.1
Content-Type: application/json

{"product_id":42,"quantity":1}

PUT

PUT обычно означает полную замену ресурса по указанному адресу. Если объект содержит десять полей, клиент при полном обновлении должен передать согласованное представление всех значимых полей. PUT часто называют идемпотентным: повторение одинакового запроса должно приводить к тому же результату.

PATCH

PATCH предназначен для частичного изменения ресурса. Он удобен, когда нужно изменить только статус, телефон или отдельный параметр, не отправляя весь объект.

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

{"phone":"+79991234567"}

DELETE

DELETE используется для удаления ресурса или запроса на его удаление. В корпоративных системах фактическое удаление может заменяться мягким удалением: объект сохраняется в базе, но помечается как неактивный.

Метод	Назначение	Типичный код успеха	Изменяет данные
GET	Получение ресурса	200	Нет
POST	Создание или запуск операции	201 или 202	Обычно да
PUT	Полная замена	200 или 204	Да
PATCH	Частичное изменение	200 или 204	Да
DELETE	Удаление	204 или 200	Да

HTTP-коды ответа в REST API

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

Код	Когда применяется	Пример
200 OK	Успешное чтение или изменение с телом ответа	Карточка статьи возвращена
201 Created	Создан новый ресурс	Создан заказ
202 Accepted	Задача принята на асинхронную обработку	Запущен импорт файла
204 No Content	Операция успешна, тело не требуется	Ресурс удалён
400 Bad Request	Некорректный запрос	Повреждённый JSON
401 Unauthorized	Нет действительной аутентификации	Истёк токен
403 Forbidden	Доступ запрещён	Нет права удалять заказ
404 Not Found	Ресурс не найден	Нет статьи с таким ID
409 Conflict	Конфликт состояния	Повторная регистрация email
429 Too Many Requests	Превышен лимит запросов	Слишком частые вызовы
500 Internal Server Error	Непредвиденная ошибка приложения	Исключение в обработчике
503 Service Unavailable	Сервис временно недоступен	Перегружен зависимый сервис

JSON и HTTP

Фраза http протокол json объединяет два разных уровня. HTTP передаёт сообщения, а JSON представляет данные внутри этих сообщений. JSON не является протоколом передачи данных: это текстовый формат сериализации объектов и массивов.

Что такое JSON

JSON расшифровывается как JavaScript Object Notation, но сегодня используется далеко за пределами JavaScript. Он поддерживает строки, числа, логические значения, массивы, объекты и специальное значение null.

{
  "id": 42,
  "title": "Основы интеграции",
  "published": true,
  "tags": ["http", "api", "rest"]
}

Популярность JSON объясняется компактностью, понятным синтаксисом и удобством обработки практически в любом языке программирования. Однако JSON не описывает саму бизнес-логику и не определяет, какой URL нужно вызвать. Эти правила задаются API.

JSON в теле HTTP-запроса

Клиент передаёт JSON в теле запроса, когда серверу нужно отправить набор структурированных данных. Это характерно для создания заказов, регистрации пользователей, фильтрации, изменения профиля и запуска операций.

POST /api/customers HTTP/1.1
Host: crm.example.ru
Content-Type: application/json
Accept: application/json

{
  "name": "Ирина Смирнова",
  "email": "irina@example.ru"
}

JSON в HTTP-ответе

В ответе JSON обычно содержит объект результата, массив элементов, метаданные пагинации или описание ошибки. Формат ответа должен быть стабильным: если сегодня поле называется customer_id, а завтра без предупреждения становится clientId, интеграция может перестать работать.

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

{
  "id": 15,
  "name": "Ирина Смирнова",
  "created_at": "2025-03-08T10:30:00Z"
}

Content-Type application/json

Заголовок Content-Type сообщает, какой формат содержится в теле сообщения. Значение application/json означает, что тело является JSON. Если клиент отправляет JSON без этого заголовка, сервер может не понять содержимое или применить неправильный обработчик.

Заголовок Accept имеет другую роль: он показывает, какой формат ответа предпочитает клиент. Например, Accept: application/json просит вернуть JSON, но не описывает формат тела запроса.

Заголовок	Что сообщает	Пример
Content-Type	Формат уже передаваемого тела	application/json
Accept	Желаемый формат ответа	application/json
Authorization	Данные аутентификации	Bearer eyJ…
Content-Length	Размер тела в байтах	128
Idempotency-Key	Ключ защиты от повторной операции	order-7815-attempt-1

JSON в HTTP — Пример

Рассмотрим полноценный запрос к условному API cio-navigator.ru. Клиент хочет создать новую статью. Он передаёт заголовок авторизации, указывает формат запроса и просит вернуть результат в JSON.

POST /api/articles HTTP/1.1
Host: cio-navigator.ru
Authorization: Bearer access-token-example
Content-Type: application/json
Accept: application/json
Idempotency-Key: article-draft-9081

{
  "title": "Как приложения взаимодействуют через HTTP",
  "slug": "kak-prilozheniya-vzaimodeystvuyut-cherez-http",
  "category_id": 7,
  "author_id": 42,
  "published": false
}

Сервер проверяет токен, существование категории и автора, уникальность адреса slug, а затем создаёт запись. Если операция выполнена успешно, он может вернуть код 201 Created и адрес созданного ресурса.

HTTP/1.1 201 Created
Location: https://cio-navigator.ru/api/articles/123
Content-Type: application/json; charset=utf-8

{
  "id": 123,
  "title": "Как приложения взаимодействуют через HTTP",
  "slug": "kak-prilozheniya-vzaimodeystvuyut-cherez-http",
  "category_id": 7,
  "author_id": 42,
  "published": false,
  "created_at": "2025-03-08T12:00:00Z"
}

Если поле title отсутствует, сервер может вернуть ошибку в согласованном формате.

HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json

{
  "error": {
    "code": "validation_failed",
    "message": "Поля не прошли проверку",
    "fields": {
      "title": ["Поле является обязательным"]
    }
  }
}

Часть примера	Значение	Практический смысл
POST	Метод	Передача данных для создания статьи
/api/articles	URL	Коллекция ресурсов статей
Host	cio-navigator.ru	Имя целевого HTTP-сервера
Authorization	Bearer-токен	Проверка личности и прав клиента
Content-Type	application/json	Формат отправленного тела
Accept	application/json	Предпочтительный формат ответа
201 Created	Код результата	Статья успешно создана
Location	Адрес ресурса	Где получить созданную статью
Тело ответа	JSON-объект	Данные нового ресурса

XML и HTTP

XML — ещё один формат представления структурированных данных. Выражение протокол http xml также требует точности: XML не является протоколом, а HTTP может переносить XML-тело так же, как JSON, текст или файл.

Что такое XML

XML использует вложенные элементы и атрибуты. Формат более многословен, чем JSON, зато хорошо поддерживает пространства имён, схемы, смешанное содержимое и сложные корпоративные документы.

<article id="123">
  <title>Как приложения взаимодействуют через HTTP</title>
  <published>false</published>
  <author>
    <id>42</id>
  </author>
</article>

XML часто встречается в государственных системах, банковском обмене, электронном документообороте, SOAP-сервисах и старых интеграциях. Его использование не означает, что система не применяет HTTP: наоборот, XML-сообщения нередко передаются именно через HTTP или HTTPS.

XML в HTTP-запросах и ответах

Для XML используется заголовок Content-Type: application/xml или, в некоторых системах, text/xml. Клиент может указать Accept: application/xml, если ожидает XML-ответ.

POST /integration/invoices HTTP/1.1
Host: accounting.example.ru
Content-Type: application/xml; charset=utf-8
Accept: application/xml

<invoice>
  <number>INV-1008</number>
  <amount currency="RUB">12500</amount>
</invoice>

Сервер может вернуть подтверждение также в XML:

HTTP/1.1 200 OK
Content-Type: application/xml; charset=utf-8

<result>
  <status>accepted</status>
  <documentId>77881</documentId>
</result>

JSON и XML — сравнение — Таблица

Оба формата могут описывать одни и те же данные. Выбор зависит от требований интеграции, существующих стандартов, инструментов и сложности документов.

Критерий	JSON	XML
Синтаксис	Объекты и массивы	Элементы и атрибуты
Размер сообщения	Обычно компактнее	Обычно больше из-за повторяющихся тегов
Читаемость	Удобен для веб-разработчиков	Хорошо описывает иерархические документы
Схемы и валидация	Возможны через внешние инструменты	Сильные стандарты XSD, DTD и другие
Пространства имён	Нет встроенного аналога	Поддерживаются
Типичное применение	REST API, мобильные и веб-приложения	Документооборот, SOAP, корпоративные стандарты

Один набор данных в JSON и XML может выглядеть так:

JSON:
{
  "id": 123,
  "title": "Интеграция",
  "published": false
}

XML:
<article>
  <id>123</id>
  <title>Интеграция</title>
  <published>false</published>
</article>

Какие механизмы и технологии работают поверх HTTP

HTTP является основой для множества прикладных решений. Важно не смешивать транспортный уровень и прикладные соглашения: HTTP переносит сообщения, а конкретная технология определяет, что эти сообщения означают.

API

API может быть реализовано поверх HTTP в виде набора конечных точек. Такой интерфейс может использовать JSON, XML, CSV, бинарные форматы или несколько вариантов одновременно. Само слово API не говорит, какой транспорт и формат выбраны.

REST API

REST API использует HTTP-методы, URL ресурсов, коды состояния и представления данных. В большинстве современных веб-приложений таким представлением является JSON, но REST не требует только JSON и не запрещает XML.

WebDAV

WebDAV расширяет HTTP возможностями удалённого управления файлами и коллекциями. Он применяется для создания, изменения, перемещения и блокировки ресурсов в сетевых хранилищах. Помимо привычных GET, PUT и DELETE, WebDAV использует дополнительные методы, например PROPFIND, MKCOL, COPY и MOVE.

Другие прикладные механизмы

Поверх HTTP также работают формы HTML, загрузка файлов, SOAP, GraphQL, серверные события и различные RPC-подходы. Они используют HTTP как канал обмена, но задают собственные правила формирования запросов и ответов.

Технология	Что задаёт	Типичный формат	Сценарий
REST API	Ресурсы, методы и представления	JSON, XML	Каталог товаров
SOAP	Формальную структуру сообщений и операции	XML	Банковские и корпоративные сервисы
GraphQL	Язык запросов к схеме данных	JSON	Сложные клиентские выборки
WebDAV	Удалённое управление файлами	XML, бинарные данные	Сетевые каталоги
HTML-формы	Отправку данных веб-страницы	URL-encoded, multipart	Регистрация и загрузка файлов

HTTP API — Пример

Ниже показан типичный запрос на получение статьи. Он не создаёт и не изменяет данные, а просит API вернуть представление ресурса в формате JSON.

GET /api/articles/123 HTTP/1.1
Host: cio-navigator.ru
Accept: application/json

Возможный ответ:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Cache-Control: public, max-age=60

{
  "id": 123,
  "title": "Как приложения взаимодействуют через HTTP",
  "slug": "kak-prilozheniya-vzaimodeystvuyut-cherez-http",
  "author": {
    "id": 42,
    "name": "Ирина Смирнова"
  },
  "published": true,
  "tags": ["http", "api", "integration"],
  "updated_at": "2025-03-08T12:00:00Z"
}

Метод GET сообщает, что клиент хочет получить данные. В корректно спроектированном API такой запрос не должен менять статью, создавать запись или запускать необратимую операцию.

URL /api/articles/123 указывает на конкретную статью с идентификатором 123. Часть /api часто используется как префикс программного интерфейса, а articles обозначает коллекцию ресурсов.

Host: cio-navigator.ru определяет имя узла, к которому обращается клиент. Этот заголовок особенно важен, когда один сервер обслуживает несколько доменов.

Accept: application/json сообщает, что клиент ожидает JSON. Это не означает, что тело запроса является JSON: у GET-запроса в данном примере тела вообще нет.

Код 200 OK означает успешное выполнение операции. Если статья не существует, API может вернуть 404 Not Found, а если доступ закрыт — 401 или 403 в зависимости от ситуации.

Content-Type: application/json в ответе указывает формат тела. Это позволяет клиенту выбрать правильный парсер и отличить JSON от XML, HTML или обычного текста.

Тело ответа содержит представление статьи: идентификатор, заголовок, автора, статус публикации и дату изменения. Вложенный объект автора показывает, что JSON способен представлять связанные данные, хотя правила вложенности должны быть заранее описаны в контракте API.

Ситуация	Ответ API	Что делает клиент
Статья найдена	200 + JSON	Показывает данные
Статья отсутствует	404 + ошибка	Показывает сообщение или страницу 404
Нет токена	401	Просит авторизоваться
Нет прав	403	Скрывает недоступную операцию
Сервер временно недоступен	503	Повторяет запрос по безопасной стратегии

HTTP в интеграциях

Интеграция — это не просто отправка одного запроса. Обычно нужно согласовать идентификаторы, справочники, авторизацию, расписание обмена, обработку повторов, журналирование и правила восстановления после сбоев.

Обмен данными между информационными системами

Например, интернет-магазин может передавать заказы в ERP, а ERP — возвращать статусы отгрузки. Магазин отправляет данные по HTTP API, корпоративная система проверяет их и отвечает идентификатором принятого заказа.

Магазин
  |
  | POST /api/v1/orders
  | JSON-заказ
  v
Интеграционный шлюз
  |
  | проверка формата и токена
  v
ERP
  |
  | 201 Created
  v
Магазин получает erp_order_id

При таком обмене важно заранее определить, какая система является источником истины. Например, магазин может владеть составом заказа, а ERP — фактическим статусом отгрузки. Без такого разделения две системы начнут перезаписывать данные друг друга, словно два человека одновременно правят один документ.

Микросервисы

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

Если сервис A ждёт сервис B, а B ждёт сервис C, временная недоступность C может постепенно затронуть всю цепочку. Поэтому для длительных операций часто применяют асинхронные очереди, а через HTTP возвращают 202 Accepted и адрес проверки статуса.

POST /api/imports HTTP/1.1
Host: data.example.ru
Content-Type: application/json

{"file_id":"upload-77","mode":"full"}

HTTP/1.1 202 Accepted
Location: /api/imports/991
Content-Type: application/json

{"job_id":991,"status":"queued"}

Веб-приложения

Фронтенд веб-приложения обращается к серверу через HTTP API для загрузки списка товаров, отправки формы, фильтрации результатов и сохранения изменений. Даже если пользователь видит красивую кнопку, за ней обычно скрывается запрос с конкретным методом, URL и телом.

Пользователь нажал «Добавить в корзину»
        ↓
POST /api/cart/items
        ↓
API проверяет товар и остаток
        ↓
JSON: {"cart_id":55,"items_count":3}

Для браузерных приложений дополнительно важны CORS, cookies, CSRF-защита, кеширование и корректная обработка preflight-запросов OPTIONS. Эти механизмы не меняют базовую модель HTTP, но влияют на то, сможет ли клиент безопасно обратиться к API.

Интеграция с внешними API

Внешний API может принадлежать платёжной системе, службе доставки, оператору связи или государственному сервису. Перед подключением нужно изучить документацию, лимиты, правила подписи запросов, тестовую среду и формат ошибок.

Система магазина
  |
  | POST /payments
  | amount=12500, order_id=7815
  v
Платёжный API
  |
  | payment_id=pay-908
  | status=pending
  v
Система магазина сохраняет идентификатор
  |
  | webhook о результате платежа
  v
Статус заказа обновляется на paid

На практике полезно учитывать следующие особенности:

• внешний сервис может временно отвечать медленно;
• один и тот же запрос нельзя бездумно повторять, если он создаёт платёж или заказ;
• формат даты, валюты и десятичных чисел должен быть согласован;
• необходимо хранить внешний идентификатор операции;
• в журналах нельзя оставлять токены и полные данные банковских карт;
• изменения версии внешнего API нужно отслеживать заранее.

Риск интеграции	Последствие	Мера защиты
Повтор POST-запроса	Двойной заказ или платёж	Idempotency-Key и проверка статуса
Тайм-аут	Неясно, выполнена ли операция	Запрос статуса по идентификатору
Изменение схемы	Ошибка разбора ответа	Версионирование и контрактные тесты
Лимит запросов	Ответы 429	Очередь, backoff и ограничение частоты
Утечка токена	Несанкционированный доступ	HTTPS, секрет-хранилище и маскирование логов
Разные справочники	Неверная интерпретация данных	Таблица соответствий и единые идентификаторы

HTTP, API, REST и JSON — чем отличаются — Таблица

Ниже сведены основные понятия. Такая таблица особенно полезна при чтении технического задания: она помогает понять, о каком именно уровне идёт речь.

Понятие	Что это	Что определяет	Пример
HTTP	Прикладной протокол	Обмен запросами и ответами	GET /api/articles/123
API	Программный интерфейс	Доступные операции и контракт	Создание заказа
REST	Архитектурный стиль	Ресурсы, ограничения и принципы взаимодействия	Статья как ресурс
REST API	API, организованное с REST-подходом	URL ресурсов, методы, представления и коды	GET /api/articles/123
JSON	Формат данных	Структуру сериализованного объекта	{«id»:123}
XML	Формат данных	Иерархию элементов и атрибутов	<id>123</id>

Иногда в документации встречаются поисковые формулировки вроде http протокол php или протокол http html. Важно понимать их по смыслу: PHP может выступать серверным языком, формирующим HTTP-ответ, а HTML — форматом содержимого, передаваемого через HTTP. Ни PHP, ни HTML не являются разновидностями HTTP.

Точно так же выражение протокол http передача данных описывает общую задачу HTTP, но не означает, что любой передаваемый формат становится частью протокола. HTTP способен переносить JSON, XML, HTML, изображения, архивы и произвольные бинарные данные.

Уровень 1: TCP/IP доставляет поток данных между узлами
Уровень 2: HTTP задаёт запрос и ответ
Уровень 3: REST определяет стиль организации API
Уровень 4: JSON или XML представляет данные

HTTP и TCP/IP

Основная статья: HTTP в сетевой модели: TCP/IP, OSI, IP, DNS и порты

HTTP относится к прикладному уровню сетевой модели. Он не занимается маршрутизацией пакетов и не определяет, как электрический или радиосигнал передаётся между устройствами. Эти задачи решаются нижележащими уровнями TCP/IP.

Упрощённая цепочка выглядит так: DNS помогает найти IP-адрес по доменному имени, IP доставляет пакеты к узлу, TCP обеспечивает надёжный поток для HTTP/1.1 и HTTP/2, а TLS шифрует соединение при HTTPS. HTTP затем описывает структуру запроса и ответа.

Уровень	Пример технологии	Роль в HTTP API
Прикладной	HTTP, REST API, JSON	Смысл запроса, ответа и данных
Транспортный	TCP, UDP, QUIC	Передача между конечными узлами
Сетевой	IP	Адресация и маршрутизация
Канальный	Ethernet, Wi-Fi	Передача в локальной сети
Службы имён	DNS	Преобразование имени в IP-адрес

При HTTP API ошибка может возникнуть на любом уровне. Если домен не разрешается, приложение не дойдёт до HTTP. Если порт закрыт, не установится соединение. Если TLS-сертификат недействителен, защищённый запрос будет остановлен. И только после успешного прохождения этих этапов можно анализировать метод, заголовки, тело и код ответа.

Частые вопросы

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

HTTP — это API?

Нет. HTTP — прикладной протокол обмена сообщениями, а API — интерфейс, описывающий доступные возможности системы. HTTP часто используется для реализации веб-API, но API может работать и через другие механизмы.

REST — это протокол?

Нет. REST — архитектурный стиль. Он описывает принципы организации взаимодействия: ресурсы, единый интерфейс, отсутствие состояния между запросами и другие ограничения. HTTP часто служит основой REST API, но сам REST транспортным протоколом не является.

Что такое REST API?

REST API — это программный интерфейс, организованный с использованием REST-подхода. Обычно он представляет сущности как ресурсы, использует URL, HTTP-методы, коды ответа и форматы вроде JSON или XML.

Использует ли REST HTTP?

На практике — очень часто. HTTP хорошо подходит для REST благодаря методам, статусам, заголовкам, кешированию и адресуемым ресурсам. Но фраза «REST — это HTTP» всё равно некорректна: REST задаёт стиль, а HTTP предоставляет механизм обмена.

Что такое JSON API?

JSON API — это API, в котором данные запросов и ответов представлены в JSON. Иногда так называют любой HTTP-интерфейс с JSON, а иногда — конкретную спецификацию JSON:API. Поэтому при интеграции нужно уточнять, имеется в виду общий формат или стандарт со строгими правилами структуры документов.

Чем JSON отличается от XML?

JSON обычно компактнее и проще для веб-приложений, мобильных клиентов и JavaScript. XML многословнее, но обладает мощными средствами описания документов, пространствами имён и формальными схемами. Ни один формат не является универсально лучшим: выбор определяется требованиями системы и уже существующими стандартами обмена.

Короткая памятка:
HTTP — как передаём сообщение.
API — какие операции доступны.
REST — как организован интерфейс.
JSON/XML — в каком виде представлены данные.
HTTPS — как защищаем HTTP-соединение.

Главный практический вывод прост: при анализе интеграции нужно отдельно проверить транспорт, контракт API, архитектурный стиль, формат данных, авторизацию, коды ошибок и правила повторной обработки. Такое разделение экономит время и помогает быстрее понять, где именно возникла проблема — в сети, HTTP-запросе, серверной логике или структуре данных.