API и интеграции: вопросы для собеседования QA

Синтаксис: ключи и строки — в двойных кавычках, пара ключ–значение через двоеточие, элементы через запятую; объекты в фигурных скобках {}, массивы — в квадратных [].

Структура: JSON строится из вложенных друг в друга объектов и массивов; базовые типы — строка, число, логическое, null, объект и массив.

В тестировании важно проверять валидность синтаксиса, обязательные поля и соответствие типов договору API.

Из практики: самая частая проблема — несоответствие типов, которое ломает клиента при корректном коде ответа.

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

Окружения и переменные нужны для быстрого переключения между стендами без правки каждого запроса вручную.

Из практики: структурированная коллекция в Postman заметно ускоряет проверку интеграций и регрессию API.

Чаще всего использую curl для быстрых проверок GET/POST, передачи заголовков, токенов и тела запроса.

Полезные флаги: -X для метода, -H для заголовков, -d для тела, -i для просмотра заголовков ответа, -v для подробного лога.

Из практики: curl хорошо помогает отделить проблему интерфейса от проблемы API за пару минут.

Retry полезен для временных сбоев сети и кратких деградаций зависимостей.

Важно ставить лимиты, backoff и jitter, иначе можно добить сервис повторными запросами.

Из практики: без backoff ретраи быстро создают лавину запросов, поэтому всегда проверяю защиту от шторма.

Таймауты выбираю от реальных SLO и измеренной латентности сервиса: connect timeout — обычно 1–5 с, read timeout — по p99 плюс запас, общий timeout — с учётом критичности операции.

Устанавливаю разные значения для connect и read; для некритичных операций делаю таймаут короче и добавляю retry с backoff; для критичных — чуть длиннее, но с чёткой обратной связью пользователю.

Из практики: слишком длинный таймаут — это зависший запрос и плохой UX; слишком короткий — ложные ошибки при временной деградации. Правильный баланс находится измерениями, а не «на глаз».

Интеграционные тесты проверяют связки компонентов и реальные контракты между ними.

В приоритете критичные пользовательские потоки, где участвуют API, БД, очереди и внешние сервисы.

Из практики: на стыке интерфейса и сервера обычно и прячутся самые неприятные дефекты.

Контрактные тесты фиксируют договорённость формата API между провайдером и потребителем.

Они быстро показывают несовместимые изменения до выкатки в общее окружение.

Из практики: хорошо работают проверки контракта в CI до деплоя — это ловит breaking changes раньше интеграционного стенда.

JSON: легковесный, читаемый, нативный для JavaScript, поддерживает объекты, массивы, строки, числа, булевы значения и null. XML: поддерживает атрибуты, namespace, XSLT-трансформации, схему (XSD) — богаче семантически, но тяжелее.

В тестировании: JSON проще парсить и проверять через JSONPath и JSON Schema; XML требует XPath и XSD. REST-API сегодня преимущественно JSON, SOAP и старые интеграции — XML.

Из практики: при тестировании XML-сервисов обязательно проверяю namespace-обработку и валидацию по XSD — там чаще всего прячутся дефекты интеграции.

Проверяю, что обязательные поля присутствуют, типы верны, ограничения длины и формата соблюдены.

Схемы запускаю автоматически в тестах, чтобы ловить несовместимые изменения сразу после коммита.

Из практики: схема особенно полезна, когда сервисами пользуются несколько команд и версий клиентов.

JSONPath позволяет точечно извлекать данные из JSON: `$.user.id` — поле id объекта user, `$.orders[0].total` — total первого заказа, `$.items[?(@.price > 100)]` — фильтрация по условию.

XPath для XML: `//order/item/@id` — атрибут id всех элементов item, `//user[status='active']` — фильтрация по значению. Использую их в Rest Assured, Postman и XML-парсерах для точных проверок.

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

Идемпотентность: повтор одного и того же запроса не меняет результат после первого успешного выполнения. Идемпотентные методы: GET, HEAD, PUT, DELETE, OPTIONS. POST и PATCH — не идемпотентны по умолчанию.

Безопасные методы не должны изменять состояние сервера: GET, HEAD, OPTIONS. Безопасность ⊂ идемпотентность (все безопасные идемпотентны, но не наоборот — PUT идемпотентен, но не безопасен).

Из практики: без проверки идемпотентности POST-запросов легко получить дубли заказов при повторной отправке. Проверяю: второй идентичный POST создаёт дубль или возвращает 409 Conflict.

Договорное тестирование фиксирует формат обмена данными между провайдером и потребителем: обязательные поля, типы, коды ответа — это «договор», который нельзя нарушить без явного согласования.

Основной инструмент — Pact: потребитель генерирует pact-файл с ожиданиями, провайдер верифицирует его в своих тестах. Запускается в CI до деплоя — breaking changes видны немедленно.

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

Сначала фиксирую входные данные и контекст ошибки: endpoint, payload, время и correlation-id.

Потом проверяю цепочку: шлюз, сервис, база, внешние зависимости и их журналы в момент сбоя.

Из практики: если быстро выделить слой проблемы, время расследования сокращается в разы.

Сравниваю контракт: открываю DevTools → Network, нахожу конкретный запрос — если API возвращает 200 с корректным телом, а интерфейс показывает не то, проблема на фронте в маппинге или форматировании.

Если API возвращает 4xx/5xx или тело ответа некорректно — иду в бэк, смотрю логи сервиса и зависимостей.

Из практики: curl или Postman позволяют проверить API напрямую без интерфейса за 30 секунд. Если curl даёт правильный ответ — проблема точно на фронте; если нет — на бэке.

REST — ресурсный подход: stateless-взаимодействие, client-server, единый интерфейс; ресурс адресуется URL, а действие задаётся методом (GET/POST/PUT/PATCH/DELETE).

Коды ответа: 2xx — успех (200 OK, 201 Created, 204 No Content); 3xx — редиректы; 4xx — ошибка клиента (400, 401, 403, 404, 409); 5xx — ошибка сервера (500, 503).

QA проверяет, что метод и код соответствуют действию и типу ошибки: создание → 201, нет авторизации → 401/403, нет ресурса → 404.

Из практики: неправильный код ответа часто ломает клиент сильнее, чем сама бизнес-ошибка.

Producer API: ключевые конфиги — `bootstrap.servers` (адрес брокеров), `acks=all` (подтверждение от всех реплик), `enable.idempotence=true` (защита от дублей), `key/value.serializer` (формат сообщений).

Consumer API: `group.id` (группа потребителей), `auto.offset.reset=earliest/latest` (с какого offset читать), `max.poll.records` (сколько сообщений за один poll), `enable.auto.commit` (автокоммит offset).

Из практики: при тестировании Consumer важно проверять `auto.offset.reset=earliest` — Consumer должен читать все сообщения, включая отправленные до его запуска. Иначе тест пропустит сообщения и даст ложный результат.

Kafka — это платформа потоковой передачи сообщений: продюсеры пишут события в топики, а консьюмеры их читают.

Ключевые элементы: брокер, топик, партиции, оффсеты и группы потребителей.

Из практики: в тестировании главное проверить не только доставку, но и поведение при повторах, задержках и перезапусках потребителя.

В RabbitMQ продюсер публикует сообщения в exchange (обменник), который маршрутизирует их в очереди. Типы exchanges: direct (по точному routing key), fanout (во все привязанные очереди), topic (по шаблону routing key), headers (по заголовкам).

Потребитель читает из очереди и подтверждает обработку через ACK. При ошибке — NACK, сообщение возвращается в очередь или уходит в dead letter queue. Durable-очереди и persistent-сообщения переживают перезапуск брокера.

Из практики: при тестировании RabbitMQ важно проверять не только успешную доставку, но и поведение при NACK, переполнении очереди и перезапуске потребителя.

Pub/Sub: продюсер публикует в fanout-exchange, все привязанные очереди получают копию — использую для рассылки событий нескольким потребителям одновременно.

Routing: direct/topic-exchange маршрутизирует по routing key — удобно для разделения потоков по типам событий. RPC-паттерн: запрос с reply_to-очередью и correlation_id, потребитель отвечает в указанную очередь.

Из практики: при тестировании RPC-паттерна отдельно проверяю тайм-аут ответа и поведение клиента при потере correlation_id — это типичный источник зависаний.

Проверяю семантику доставки и обработки: порядок в рамках партиции, распределение по consumer groups, коммит офсетов и повторную обработку при ребалансе.

Контролирую идемпотентность продюсера и exactly-once, поведение при сбое брокера, ретраи и dead letter, а также дубликаты у потребителя.

Мониторю consumer lag, задержки и throughput под нагрузкой (метрики JMX/Kafka).

Из практики: важно проверять не только «сообщение дошло», но и корректность обработки на стороне потребителя при дубликатах и переупорядочивании.

Договорное тестирование ловит, что изменение интерфейса сломает соседний сервис; использую consumer-driven контракты (например, Pact).

Проверки запускаю в CI, чтобы несовместимость ловилась до релиза.

Контрактами управляю через брокер (Pact Broker / реестр схем): там публикуются и версионируются контракты, а can-i-deploy проверяет совместимость версий перед выкладкой.

Из практики: после внедрения договорных проверок число внезапных интеграционных падений заметно падает.

В event-driven архитектуре проверяю: событие публикуется с правильной схемой и routing key; потребитель получает его и обрабатывает корректно; повторная доставка не создаёт дубли (идемпотентность).

Тестирую сценарии: потеря события, нарушение порядка, задержка доставки, переполнение очереди, поведение dead letter queue при ошибке обработчика.

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

При тестировании проверяю доставку, подтверждение (ack), повторы и обработку дублей, отдельно прогоняю падение потребителя и восстановление очереди.

Для мониторинга слежу за метриками очередей: глубина очереди, consumer lag, скорость публикации/потребления, число unacked-сообщений.

Настраиваю алерты на рост очереди и отдельно мониторю DLQ (dead-letter): попадание сообщений туда — сигнал проблем обработки.

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

Сначала проверяю Network: уходит ли запрос, какой статус.

Если API отвечает успехом, проверяю транзакцию и запись в БД, затем кеш/очереди/асинхронные обработчики.

Из практики: в отладке решает не догадка, а последовательность шагов — логи, запросы, данные, гипотеза, проверка.

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

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

Из практики: версионирование ломается не в happy-path, а на старых клиентах с неполным набором параметров.

Обязательные негативные проверки: пустые и неверные параметры, неправильные типы, отсутствие авторизации, невалидные идентификаторы.

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

Из практики: именно негативные кейсы чаще всего находят критичные проблемы интеграции.

Повторяю один и тот же запрос несколько раз и проверяю, что система не создаёт дубли и не уходит в неконсистентное состояние.

Для операций записи смотрю ключ идемпотентности и поведение при сетевом разрыве или повторной отправке.

Из практики: такие проверки особенно важны для платежей и заказов.

Проверяю, для каких ошибок разрешён повтор, сколько попыток допускается и какие интервалы между ними.

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

Из практики: корректный механизм повторов сильно повышает устойчивость интеграции, но только при чётких ограничениях.

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

Оцениваю тайм-ауты, fallback, сообщения об ошибке и возможность безопасного повтора операции.

Из практики: пользователю важнее предсказуемый отказ, чем бесконечное ожидание без ответа.

Проверяю подлинность события, корректность подписи и обработку повторной доставки.

Тестирую задержки, нарушение порядка событий и дубли, чтобы убедиться в устойчивости обработки.

Из практики: без защиты от дублей вебхуки часто приводят к повторным операциям.

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

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

Из практики: это сильно сокращает число интеграционных падений после выкладки.

Сначала разделяю класс ошибок по коду: 4xx обычно указывает на проблему запроса клиента, 5xx — на проблему сервера.

Дальше подтверждаю гипотезу по журналам, входным данным и воспроизведению запроса вне интерфейса.

Из практики: самый быстрый путь — повторить запрос через отдельный клиент и сверить трассировку.

Проверяю пакет с частично валидными данными: как система отвечает и как маркирует успешные и ошибочные элементы.

Смотрю лимиты размера пакета, время обработки и корректность повторной отправки после частичной ошибки.

Из практики: основной риск пакетных операций — потеря прозрачности результата для клиента.

Сверяю форматы, типы и обязательность полей на каждом стыке между сервисами.

Проверяю, как трактуются пустые значения, округления и часовые пояса, чтобы не было расхождения данных.

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

Сравниваю ключевые поля в источнике и потребителе: идентификаторы, статусы, суммы, временны́е метки — ищу расхождения через SQL-запросы к обеим БД или через API.

Проверяю задержку синхронизации (eventual consistency) и правила повторной обработки при сбое: данные должны сойтись за известное время, а не оставаться навсегда рассинхронизированными.

Из практики: рассинхрон часто проявляется только на нагрузке — добавляю проверку консистентности после стресс-сценариев, не только в штатном потоке.

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

Настраиваю оповещения на аномалии: резкое изменение объёма, рост доли null-значений, нарушение ссылочной целостности — команда видит проблему до того, как она попадёт в отчёты.

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

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

Отдельно посмотрю права доступа, кэш и формат данных, особенно даты, суммы и пустые поля.

Из практики: чаще всего проблема не в записи, а в чтении или маппинге данных на клиенте.

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

Проверю тайм-ауты, пулы соединений, лимиты и пики нагрузки в моменты ошибок.

Из практики: редкие 502/504 часто связаны с деградацией зависимости или неверными настройками тайм-аутов.

REST — это архитектурный стиль для API. Ключевые принципы: stateless (сервер не хранит сессионного состояния между запросами), unified interface (стандартные методы и URL), client-server разделение, кешируемость, layered system.

Ресурсы адресуются URL, действия — HTTP-методами, формат — обычно JSON.

Из практики: «настоящий REST» (HATEOAS, гипермедиа) редко используется. Чаще встречается «REST-style» — пометки и URL по REST, без полного следования.

Contract testing — проверка, что producer и consumer договорились о формате API. Consumer описывает ожидания, producer проверяет, что соблюдает.

Инструменты: Pact, Spring Cloud Contract. Особенно ценно в микросервисах — заменяет тяжёлые e2e тесты.

Из практики: contract test ловит сценарий «producer изменил поле, consumer ещё не готов» до релиза. Это устраняет целую категорию интеграционных багов.

Postman — GUI-инструмент для тестирования API. Возможности: формирование запросов, коллекции и окружения, переменные, тестовые скрипты на JavaScript, mock-серверы, документация.

Также CLI-режим (newman) для запуска в CI.

Из практики: для ручного тестирования API и быстрого прототипирования — стандарт. Для больших test-suite лучше код на JS/Java.

gRPC — протокол удалённого вызова процедур (RPC) на основе HTTP/2 и Protocol Buffers. Бинарный формат, strict-схема, поддержка streaming.

Отличия от REST: контракт через .proto файл, бинарный (не JSON), bidirectional streaming, lower latency.

Из практики: gRPC для микросервисов внутри backend. REST/JSON для browser-API и публичного API. Тестировать gRPC сложнее — нужны специальные клиенты (grpcurl, BloomRPC).

GraphQL — язык запросов: клиент указывает, какие именно поля нужны. Один эндпоинт (обычно POST /graphql), schema-first, типизированные ответы.

Подводные камни: N+1 на стороне сервера (DataLoader решает), сложность кеширования (нет URL-based), authorization на уровне резолверов.

Из практики: для UI с гибкими требованиями к данным — отлично. Для строгих контрактов — REST/gRPC обычно проще.

Синхронное взаимодействие — отправитель ждёт ответ от получателя. Поток вызова блокируется до завершения обработки. Пример: REST-запрос на оплату.

Асинхронное — отправитель не ждёт. Сообщение уходит в посредник (очередь, шину), получатель обрабатывает в своём темпе. Пример: уведомление о статусе доставки через Kafka.

Из практики: выбор зависит от того, нужен ли результат прямо сейчас. Если ответ нужен для следующего шага — sync. Если только факт «доставлено для обработки» — async.

Синхронный запрос всегда возвращает ответ — даже если это ошибка или таймаут. Иначе вызывающая сторона зависает.

Асинхронный — не обязательно немедленно. Может быть «accepted» подтверждение, а результат придёт позже отдельным каналом (callback, polling, message в обратной очереди). Бывают «fire and forget» (для уведомлений), где ответа не ждут вообще.

Из практики: для async всегда явно описываю в контракте, как и когда возвращается результат и что считать «доставкой».

Когда результат нужен здесь и сейчас для следующего действия: онлайн-оплата (ждём результат авторизации), 3DS, проверка остатков на складе перед резервированием, аутентификация.

Часто это операции с пользовательским опытом — пользователь стоит и ждёт. Без синхронного ответа интерфейс не сможет показать «оплачено/ошибка».

Из практики: если на UI «крутилка» — почти всегда внутри sync-вызов. Но даже его можно сделать «псевдо-async» через polling/long-polling, если процесс долгий.

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

Дополнительно: буфер при пиковых нагрузках, повторная доставка при сбоях, ретраи, fan-out на несколько потребителей, упорядочивание (где поддерживается).

Из практики: очередь — это не только «inbox». Это контракт с гарантиями доставки, повторами и dead-letter.

В подавляющем большинстве случаев — синхронное. Приложение отправляет запрос, ждёт ответа БД (результат или ошибку), и только потом продолжает.

Бывают исключения: некоторые СУБД и драйверы поддерживают асинхронные API на уровне сети, но логически вызов всё равно ждёт результат. «По-настоящему» async вызов — через job-таблицу или очередь, где БД-процедура запускается фоном.

Из практики: «асинхронная» работа с БД на уровне приложения — это всегда внешний механизм (очередь, шедулер), а не свойство самой БД.

API (Application Programming Interface) — программный интерфейс взаимодействия систем. Описывает, как одна программа может вызвать функциональность другой: какие запросы, какие данные, какие ответы.

Применяется везде, где системы должны общаться: интеграции внутри компании, внешние сервисы (платежи, карты, ID), мобильное и веб-приложение с бэкендом, экосистема партнёров.

Из практики: API — это контракт. Если контракт нечёткий, страдают все стороны. Поэтому первый шаг любой интеграции — согласование API, а не код.

REST (REpresentational State Transfer) — архитектурный стиль Roy Fielding для распределённых систем поверх HTTP. Не протокол и не стандарт — набор принципов.

Принципы: client-server, stateless, cacheable, uniform interface (единый интерфейс через методы и ресурсы), layered system (можно прокси/балансировщики), code-on-demand (опционально).

Из практики: большинство «REST API» в продакшене — это HTTP API, не строго REST. Полный набор HATEOAS почти не встречается.

RESTful — приложение, чей API следует принципам REST. На практике под этим понимают: ресурсо-ориентированные URL, использование HTTP-методов по семантике, statelessness, осмысленные коды ответов, согласованный формат (обычно JSON).

Степень соблюдения REST — это шкала (Richardson Maturity Model 0–3). Большинство API застревают на уровне 2 (методы + статусы), уровень 3 (HATEOAS) встречается редко.

Из практики: формальная «RESTful-чистота» — не самоцель. Важнее предсказуемость для потребителя: одинаковая структура URL, одинаковая логика ответов.

Stateless — каждый запрос содержит всю необходимую информацию для обработки. Сервер не хранит состояние сессии между запросами. Аутентификация — через токен в каждом запросе, не через серверную сессию.

Это даёт горизонтальное масштабирование (любой инстанс может обработать любой запрос), отказоустойчивость (потеря инстанса не теряет состояние), кэшируемость.

Из практики: «stateless» — это про прикладной протокол. Состояние всё равно где-то живёт (БД, токен у клиента) — просто не в памяти веб-сервера.

Path — идентификатор ресурса в URL (`/orders/123`). Query — фильтры, пагинация, опции (`?status=paid&page=2`). Header — метаданные: аутентификация, content-type, кэш, корреляция. Body — основные данные операции (JSON-тело POST/PUT/PATCH).

Правила: идентификатор — в path; фильтры — в query; авторизация/служебка — в header; сложные структуры — в body.

Из практики: токен и приватные данные не должны лежать в URL (path/query) — попадают в логи прокси и историю браузера.

Схема (`https`) + хост (`api.example.com`) + порт (опц.) + путь (`/v1/orders/123`) + query-параметры (`?status=paid`) + фрагмент (`#section`, не отправляется на сервер).

В REST путь обычно строится по схеме «ресурс/идентификатор/субресурс»: `/orders/123/items/5`. Версия часто в начале пути (`/v1/...`) или в заголовке.

Из практики: чёткая структура URL — основа предсказуемого API. Если каждый эндпоинт устроен по своему — потребители делают ошибки.

200 OK — запрос успешен, ответ содержит результат. Подходит для GET/PUT/PATCH/DELETE с возвратом тела.

201 Created — запрос успешно создал новый ресурс. Должен сопровождаться заголовком Location со ссылкой на созданный ресурс. Подходит для POST (или PUT с созданием).

Из практики: разница важна для потребителя — 201 даёт ему URL новой сущности без лишних запросов.

401 Unauthorized — клиент не аутентифицирован: токена нет, истёк, невалиден. По стандарту должен сопровождаться WWW-Authenticate-заголовком. «Кто ты?» — неизвестно.

403 Forbidden — клиент аутентифицирован, но не имеет прав на эту операцию. «Кто ты — знаю, делать это тебе нельзя».

Из практики: путаница 401/403 — частая ошибка. Если клиент не залогинен — 401. Если залогинен, но не админ — 403.

GET — получение данных. Безопасен (не меняет состояние), идемпотентен, кэшируется, параметры в URL, тело обычно не используется. Подходит для повторного выполнения без последствий.

POST — создание ресурса или нестандартная операция. Не безопасен, не идемпотентен (по умолчанию), не кэшируется, параметры в теле, может изменять состояние.

Из практики: ставить POST вместо GET «потому что параметры длинные» — антипаттерн. Лучше переделать API или использовать POST с осознанием, что теряется кэш и идемпотентность.

PUT — полная замена ресурса. Клиент посылает целиком новое представление. Если поле опустить — оно очистится (или сбросится в default).

PATCH — частичное изменение. Клиент посылает только те поля, которые нужно изменить. Форматы PATCH — JSON Merge Patch (RFC 7396) или JSON Patch (RFC 6902).

Из практики: PUT кажется проще, но в проде чаще удобнее PATCH — клиент не обязан знать все поля и не затирает чужие изменения.

POST создаёт ресурс по URL коллекции (`POST /orders` — сервер сам сгенерирует id). Не идемпотентен: два одинаковых POST = два ресурса.

PUT создаёт или заменяет ресурс по конкретному URL (`PUT /orders/123` — клиент сам решает id). Идемпотентен: повтор не создаст второй.

Из практики: если ID назначает клиент (например, UUID) — PUT удобнее. Если ID назначает сервер (auto-increment) — POST.

Да, DELETE идемпотентен по определению. Повторный DELETE того же ресурса не приводит к новому изменению — ресурса уже нет.

По коду ответа: первый DELETE возвращает 200/204, повторный — 404 (или тоже 204, если так договорились). Состояние сервера одинаковое — это и есть идемпотентность.

Из практики: разница в коде ответа не нарушает идемпотентности. Главное — состояние не меняется при повторе.

Через ключ идемпотентности (Idempotency-Key в заголовке). Клиент генерирует уникальный ключ (UUID) на каждую логическую операцию. Сервер сохраняет результат первого вызова с этим ключом и при повторах возвращает тот же ответ, не выполняя операцию повторно.

Хранят ключи с TTL (например, сутки). Используется в платёжных API (Stripe, PayPal), в банковских интеграциях, в любых критичных POST.

Из практики: для финансовых операций idempotency-key обязателен. Без него ретраи клиента легко удваивают платежи.

Технически — да, по семантике REST — нежелательно. POST для GET-задач теряет кэш, нарушает ожидания потребителя и плохо мониторится.

Оправданные исключения: сложные фильтры, не помещающиеся в URL (длинные списки ID, поиск с десятками полей); запросы с приватными данными в теле (не должны попадать в логи); GraphQL (там это норма).

Из практики: если решили использовать POST для чтения — обязательно явно документируйте это в API-описании, иначе через год никто не поймёт, почему «POST не пишет».

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

Важно в распределённых системах: сеть теряет ответы, клиенты делают ретраи, очереди гарантируют at-least-once. Без идемпотентности повторы создают дубли заказов, двойные платежи, лишние списания.

Из практики: правило — все критичные операции должны быть идемпотентными по проектированию (через natural key, idempotency-key, или сравнение состояния).

Совместимость держится на правиле «только добавлять, не ломать»: новые поля в ответе — опциональные, новые методы — отдельные эндпоинты, deprecation — через предупреждение и переходный период.

Новая версия — когда нужны breaking changes: переименование/удаление поля, изменение типа, изменение семантики, новые обязательные поля в запросе.

Из практики: не плодите версии без необходимости. Каждая новая версия = сопровождение, документация, миграция клиентов. Часто разумнее аккуратно эволюционировать v1.

OpenAPI (бывш. Swagger) — спецификация для описания REST API в машинно-читаемом формате (YAML/JSON). Содержит эндпоинты, методы, схемы запросов и ответов, аутентификацию, примеры.

Применение: автогенерация документации (Swagger UI/Redoc), генерация клиентских SDK и server-stubs, контрактное тестирование, mock-серверы.

Из практики: «контракт как код» в OpenAPI меняет процесс. Аналитик пишет спецификацию, фронт и бэк параллельно используют её для разработки и моков.

HTML — язык разметки для отображения контента в браузере. Фиксированный набор тегов с предопределённой семантикой (h1, p, div). Толерантен к ошибкам — браузер пытается отобразить даже невалидную разметку.

XML — расширяемый язык разметки для передачи и хранения структурированных данных. Теги придумывает разработчик. Строго валидируется по схеме (XSD). Не привязан к отображению.

Из практики: HTML — про вид, XML — про данные. Когда нужно обмениваться данными между системами — XML (или JSON), не HTML.

XML-декларация (`<?xml version="1.0" encoding="UTF-8"?>`), один корневой элемент, вложенные элементы с открывающим и закрывающим тегами, атрибуты, текстовое содержимое, комментарии (`<!-- -->`), CDATA-секции (`<![CDATA[...]]>`) для текста с спецсимволами.

Может ссылаться на DTD или XSD-схему для валидации. Может использовать пространства имён (xmlns) для разрешения конфликтов тегов.

Из практики: проблемы XML чаще всего — кодировка (UTF-8 vs Windows-1251) и спецсимволы (& < > в значениях).

XSD (XML Schema Definition) — стандарт описания схемы XML-документа: какие элементы, типы данных, обязательность, порядок, кардинальность, ограничения значений. Сам пишется на XML.

Используется для валидации входящих XML, генерации стабов клиента/сервера, документирования контракта. Богаче DTD по типам и возможностям.

Из практики: писать с нуля приходится редко — обычно XSD идёт от поставщика SOAP-сервиса или генерируется из WSDL. Но читать и понимать — обязательный навык.

Namespace — механизм избежания конфликтов имён, когда в одном документе встречаются теги из разных источников. Привязывается через атрибут `xmlns:prefix="URI"` и используется через префикс (`<prefix:tag>`).

URI — это идентификатор, не обязательно живой адрес. Главное — уникальность. Часто используют схему-домен вроде `http://schemas.example.com/orders/v1`.

Из практики: namespace критичен в SOAP. Сам конверт — Envelope, Header, Body — живёт в едином SOAP-namespace, а прикладные данные внутри Body лежат в своём отдельном namespace. Перепутаешь или пропустишь — сообщение не пройдёт валидацию.

SOAP (Simple Object Access Protocol) — XML-протокол обмена сообщениями. Формализован W3C, не привязан к транспорту (HTTP, SMTP, JMS).

Структура сообщения: Envelope (корневой), Header (опциональные метаданные — аутентификация, маршрутизация), Body (полезная нагрузка), Fault (стандартный формат ошибок: faultcode, faultstring, detail).

Из практики: SOAP активно используется в банках, страховании, госсистемах. На новых проектах редко выбирают SOAP, но интеграции с legacy — частая задача.

WSDL (Web Services Description Language) — XML-описание SOAP-сервиса: какие операции доступны, какие типы данных в запросе/ответе, по какому URL и протоколу вызывать.

Аналог OpenAPI для REST. По WSDL можно автоматически сгенерировать клиент и серверные стабы практически в любом языке (Java, .NET, Python).

Из практики: WSDL — это контракт. Если поставщик его меняет, нужно перегенерировать клиенты у потребителей. Поэтому изменения версионируют.

SOAP — протокол с жёсткой структурой (Envelope, WSDL, XSD), не привязан к транспорту, поддерживает встроенные стандарты (WS-Security, WS-ReliableMessaging). REST — архитектурный стиль поверх HTTP, гибкий формат данных (обычно JSON), легковесный.

SOAP уместен в строго регламентированных средах (финтех, госуслуги, B2B-интеграции). REST — почти везде в современных веб- и мобильных приложениях.

Из практики: на новых проектах REST по умолчанию. SOAP — когда так требует контрагент или регулятор.

Когда нужно: 1) развязать отправителя и получателя; 2) сгладить пики нагрузки; 3) гарантировать доставку при сбоях; 4) fan-out — одно сообщение многим потребителям; 5) последовательно обрабатывать длинные задачи в фоне.

Самые ходовые: RabbitMQ (классический брокер на AMQP), Kafka (лог-стриминг, высокая пропускная), AWS SQS / Google Pub-Sub (managed), ActiveMQ, NATS.

Из практики: выбор зависит от характеристик. Простой workflow с очередями — RabbitMQ. Аналитика событий и streaming — Kafka. Managed без эксплуатации — облачный SQS.

RabbitMQ — классический брокер с маршрутизацией (exchanges, queues), pull/push доставка, сообщение исчезает из очереди после ack. Заточен на надёжную доставку конкретному потребителю.

Kafka — распределённый лог сообщений. Сообщения не удаляются после чтения, хранятся по retention-политике. Потребители читают по offset. Высокая пропускная способность, легко добавлять новых потребителей задним числом.

Из практики: «классические очереди задач» (отправить письмо, обработать платеж) — RabbitMQ. Event-streaming, аналитика, аудит, change-data-capture — Kafka.

At-most-once — сообщение доставляется 0 или 1 раз. Просто, но возможна потеря. At-least-once — доставка минимум 1 раз, возможны дубли. Чаще всего на практике. Exactly-once — ровно 1 раз. Сложно и дорого, требует идемпотентности на стороне потребителя и поддержки на брокере (Kafka — exactly-once в рамках темы с transactions).

Выбор зависит от бизнес-смысла. Метрики/логи — at-most-once норм. Бизнес-операции — at-least-once + идемпотентность.

Из практики: «exactly-once без проектирования идемпотентности» — миф. Даже Kafka EOS требует, чтобы потребитель умел обрабатывать дубли.

Kafka хранит сообщения в логе по retention. Каждый consumer group хранит свой offset (позицию). Можно сбросить offset на: начало (earliest), конец (latest), конкретное время, конкретное значение через seek.

Способы: kafka-consumer-groups.sh --reset-offsets, API consumer.seek(), создать новую consumer group (она начнёт с earliest, если auto.offset.reset=earliest).

Из практики: «перечитать прошлое» — одна из главных причин выбора Kafka. Reprocess данных после баг-фикса — типовой кейс.

Queue (point-to-point) — каждое сообщение доставляется одному потребителю из пула. Несколько потребителей делят нагрузку, но сообщение получает только один.

Topic (publish-subscribe) — сообщение доставляется ВСЕМ подписчикам. Каждый получает свою копию. Используется для fan-out.

Из практики: одну и ту же логику можно реализовать в Kafka (через consumer groups) и в RabbitMQ (через exchanges). Главное — понимать целевую семантику.

ESB (Enterprise Service Bus) — централизованная инфраструктура интеграции в крупных организациях. Принимает сообщения от одних систем, преобразует формат, маршрутизирует и доставляет другим. Часто включает оркестрацию процессов.

Типичные функции: маршрутизация, преобразование (XML↔JSON, mapping), мониторинг, безопасность, оркестрация. Примеры: IBM Integration Bus, MuleSoft, WSO2, Sonic.

Из практики: ESB — наследие SOA-эпохи. На новых проектах чаще используют событийные подходы (Kafka), API-Gateway и микросервисы вместо тяжёлой шины.

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

ESB — высокоуровневая инфраструктура интеграции. Использует очередь как один из транспортов, добавляет преобразование, маршрутизацию по правилам, оркестрацию, протокольную совместимость (HTTP↔SOAP↔JMS).

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

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

ETL (Extract-Transform-Load) — пакетная загрузка данных в аналитическое хранилище. Большие объёмы, по расписанию (ночью), для отчётов и BI. ELT — современная вариация, где трансформация в хранилище.

Из практики: ESB обслуживает OLTP, ETL — OLAP/DWH. Это разные миры, хоть оба занимаются «движением данных».

Сначала определяю, кто отправитель и кто получатель этих полей. Если поля обязательны на ВХОДЕ сервиса, ESB и все источники должны их теперь передавать — иначе вызов упадёт.

Действия: 1) обновить WSDL/XSD/контракт сервиса; 2) обновить маппинг в ESB — откуда брать новые поля (источник, дефолт, вычисление); 3) синхронно или поэтапно обновить источники; 4) предусмотреть обратную совместимость: переходный период, дефолты, версионирование.

Из практики: добавление обязательных полей — breaking change. По-хорошему это новая версия сервиса с deprecation старой. Иначе все источники нужно обновлять одновременно.

GraphQL — язык запросов и runtime от Facebook. Клиент описывает, ровно какие поля и связанные сущности ему нужны. Сервер отдаёт ровно это. Один эндпоинт (`/graphql`) на всё.

Плюсы: нет over-fetching (берём только нужные поля), не нужно много версий API, удобно для богатых клиентов. Минусы: сложнее кэшировать (POST вместо GET), легко загнать БД тяжёлыми запросами, кривая обучения.

Из практики: GraphQL хорош для front-end-heavy приложений с разными view и для BFF. Для машинных b2b-интеграций часто REST/gRPC проще.

WebSocket — протокол двустороннего постоянного соединения поверх TCP/HTTP. После handshake клиент и сервер могут обмениваться сообщениями в обе стороны без новых запросов.

Использовать: чаты, real-time-уведомления, котировки, коллаборативные редакторы, игры. Везде, где сервер должен сам push'ить данные клиенту без polling.

Из практики: WebSocket — это про low-latency двустороннюю связь. Если push идёт только от сервера и редко — Server-Sent Events проще.

gRPC — RPC-фреймворк от Google поверх HTTP/2 с бинарной сериализацией Protocol Buffers (Protobuf). Строгая схема .proto файла, поддержка streaming в обе стороны, автогенерация клиентов для многих языков.

Уместен для межсервисного взаимодействия в микросервисной архитектуре, где важны производительность и контракт. Не подходит напрямую для браузеров (нужен gRPC-Web).

Из практики: внутри платформы — gRPC между сервисами часто оправдан. Наружу — REST или GraphQL, потому что клиенты разные.

Webhook — HTTP-callback: при событии источник делает POST на URL, который зарегистрировал получатель. Push-модель «событие случилось — мы тебя пнули».

Плюсы: простота, минимум инфраструктуры, реальный time. Минусы: получатель должен быть доступен (нужен retry, очередь, dead-letter), безопасность (подпись сообщений), сложно гарантировать порядок.

Из практики: webhook прекрасен для интеграций «снаружи внутрь» (платежи, GitHub события). Обязательны подпись, idempotency-key и логирование входящих.

Файловый обмен — интеграция через выкладку файлов (CSV, XML, Excel) в общую папку, FTP/SFTP, S3. Получатель забирает по расписанию.

Плюсы: простота, не требует онлайн-связи между системами, легко аудитить. Минусы: задержка (batch), нет реального времени, проблемы с большими файлами, обработка ошибок и повторы — на стороне получателя, нет гарантий доставки.

Из практики: до сих пор много где живо — банки, регуляторные выгрузки, ERP-интеграции. На новых проектах используют когда контрагент «иначе не умеет».

Long polling — клиент делает HTTP-запрос, сервер не отвечает сразу: держит запрос открытым до появления новых данных или таймаута. Получив ответ, клиент сразу делает новый запрос.

Отличие от WebSocket: WS — постоянное двустороннее соединение после handshake. Long polling — серия отдельных HTTP-запросов с задержанным ответом, только сервер→клиент.

Из практики: long polling — fallback, когда WS недоступен (старые прокси, ограничения сети). WS эффективнее по ресурсам, но сложнее в эксплуатации.