Как гарантировать, что изменение вашего API не сломает потребителей, которых вы не контролируете?
- Как не сломать потребителей API при изменениях?
- Что такое consumer-driven contract testing?
По уровням: дисциплина совместимых изменений → схема как источник истины → автоматическая проверка совместимости в CI → контрактные тесты от потребителей.
- Схема (OpenAPI, protobuf, Avro) — первична; из неё генерируются клиенты и документация
- Диф схем в сборке: ломающее изменение валит пайплайн
- Consumer-driven contracts (Pact): потребители фиксируют, что им нужно, провайдер проверяет каждый релиз
А ещё Неизбежные изменения — expand–contract, метрики использования старой версии и политика поддержки
Подробно
1. Дисциплина изменений. По умолчанию — только добавления; клиенты — толерантные читатели.
2. Схема — источник истины. OpenAPI для REST, protobuf для gRPC, Avro/JSON Schema для событий. Клиенты генерируются из схемы, а не пишутся по документации, которая отстаёт от кода.
3. Автоматическая проверка совместимости. В CI сравнивается новая схема со старой (openapi-diff, buf breaking для protobuf); для событий — Schema Registry с режимом совместимости BACKWARD или FORWARD: реестр не даст зарегистрировать ломающую версию.
4. Контрактные тесты, управляемые потребителем. Каждый потребитель описывает запросы, которые он делает, и поля, которые читает (Pact). Провайдер в своей сборке проверяет, что удовлетворяет всем опубликованным контрактам, — и узнаёт о поломке до выкатки. Это позволяет отказаться от хрупких сквозных тестов всей системы и общего релизного поезда.
5. Когда ломать необходимо: expand–contract (новое рядом со старым), метрики, кто ещё зовёт старую версию (по заголовку клиента или ключу API), объявленный срок поддержки и уведомление потребителей.
Что хотят услышать
- Многоуровневый ответ, а не одна мера.
- Схема как первичный артефакт и проверка совместимости в CI.
- Контрактные тесты от потребителей и чем они лучше сквозных.
- Процесс для неизбежных ломающих изменений.
Частые ошибки
- Полагаться только на документацию и внимательность.
- Проверять совместимость сквозными тестами всей системы.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✓Совместимые изменения, схема как источник истины, проверка совместимости в CI, контрактные тесты
- ✗Предупреждать потребителей письмом за неделю до релиза
- ✗Сквозные тесты со всеми потребителями
- ✗Выпускать новую мажорную версию API на каждое изменение, а старую отключать через месяц
Что спросят дальше
- Как вы узнаете, что старой версией больше никто не пользуется?
- Чем контрактные тесты отличаются от тестов по схеме?
Разбор темы
- Проектирование API: REST, gRPC и события
Выбор стиля взаимодействия, семантика и идемпотентность HTTP, формат ошибок, курсорная пагинация против offset, версионирование и обратная совместимость, контрактное тестирование.
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.