Проверяйте контракт на реальных ожиданиях клиентов, а не только серверной схеме. Даже добавление поля может сломать строгий parser, подпись payload или клиентскую бизнес-логику.
Вы хорошо описали подход к тестированию разных версий API. А как вы проверяете, что изменения в API не нарушают работу клиентов, особенно при добавлении новых полей?
Проверяйте контракт на реальных ожиданиях клиентов, а не только серверной схеме. Даже добавление поля может сломать строгий parser, подпись payload или клиентскую бизнес-логику.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Проверяйте контракт на реальных ожиданиях клиентов, а не только серверной схеме. Даже добавление поля может сломать строгий parser, подпись payload или клиентскую бизнес-логику.
Полезны consumer-driven contract tests, проверка старых SDK и интеграционные сценарии с предыдущими версиями клиентов. Убедитесь, что неизвестные поля обрабатываются допустимо, обязательность старых полей не изменилась, а новые значения enum не приводят к падению. Сравнивайте schema-diff, но не полагайтесь только на него. Выкатывайте изменение постепенно и наблюдайте ошибки по версиям клиента. Для несовместимой семантики нужен план миграции и, при необходимости, новая версия API.