В каком формате писать ответ (XML, JSON, YAML)
Что проверяют
Умеете ли вы выбрать формат обмена исходя из интеграции, а не из вкуса, и описать его так, чтобы разработчики с обеих сторон реализовали одно и то же. Следом обычно спрашивают, как вы задокументируете контракт и опишете ошибки.
Как отвечать
Покажите, что выбор диктует потребитель и тип интеграции:
- JSON: стандарт для REST и фронтенда,
Content-Type: application/json. Контракт описывают в OpenAPI, структуру фиксируют через JSON Schema. Комментариев нет, а числа в JavaScript этоdouble, поэтому большие идентификаторы надёжнее передавать строкой, а суммы целым числом в копейках или строкой; - XML: SOAP-сервисы, банковские и государственные интеграции (СМЭВ, сообщения ISO 20022). Схема задаётся в XSD и проверяется валидатором, контракт SOAP в WSDL. Многословный, зато строгий: пространства имён, типы, обязательность полей;
- YAML: не для ответов API, а для того, что читает и правит человек: конфигурации, манифесты Kubernetes, сама спецификация OpenAPI.
Дальше перечислите, что вы зафиксируете в требованиях к ответу независимо от формата: кодировку UTF-8, даты в ISO 8601 с часовым поясом, именование полей (camelCase или snake_case, но одно на весь API), разницу между null и отсутствующим полем, пример успешного ответа и формат ошибки. Для ошибок в REST есть готовый стандарт Problem Details (RFC 9457). Для внутренних сервисов под высокой нагрузкой можно упомянуть Protobuf в gRPC как бинарную альтернативу.
Где спотыкаются
Выбирают формат по личному удобству. Если принимающая сторона это государственный сервис на SOAP, вопрос о JSON просто не стоит.
Предлагают YAML для ответа API. Он чувствителен к отступам, а парсеры по старой спецификации YAML 1.1 превращают значения вроде no в false, и такие ошибки дорого ловить на проде.
Сдают только описание полей без схемы и примеров. Без XSD или JSON Schema каждая команда прочитает контракт по-своему, и расхождения всплывут на интеграционном тестировании.