Я читал о стратегиях управления версиями API-интерфейсов REST, и что-то, о чем никто из них не обращается, - это то, как вы управляете базовой базой кода.
Предположим, что мы вносим некоторые изменения в API - например, меняем ресурс Customer, чтобы он возвращал отдельные поля forename и surname вместо одного поля name. (В этом примере я буду использовать решение для управления версиями URL-адресов, поскольку он легко понимает связанные с ним понятия, но вопрос в равной степени применим к согласованию контента или пользовательским HTTP-заголовкам)
Теперь мы имеем конечную точку в http://api.mycompany.com/v1/customers/{id} и другую несовместимую конечную точку в http://api.mycompany.com/v2/customers/{id}. Мы по-прежнему выпускаем исправления и обновления для системы безопасности для API v1, но теперь новая разработка функций сосредоточена на v2. Как мы пишем, тестируем и развертываем изменения на нашем сервере API? Я вижу как минимум два решения:
-
Используйте ветку/тег управления источника для кодовой базы v1. v1 и v2 разрабатываются и развертываются независимо друг от друга, при этом контроль версий сглаживается, если необходимо, для применения одного и того же исправления к обеим версиям - аналогично тому, как вы управляете кодовыми базами для родных приложений при разработке новой новой версии, сохраняя при этом предыдущую версию.
-
Предоставьте самой базе кода информацию о версиях API, поэтому вы получите единую кодовую базу, которая включает как представление клиента v1, так и представление клиента v2. Обращайтесь с версиями как частью архитектуры решения вместо проблемы с развертыванием - возможно, используя некоторую комбинацию пространств имен и маршрутизации, чтобы убедиться, что запросы обрабатываются с помощью правильной версии.
Очевидным преимуществом модели ветки является то, что тривиально удалять старые версии API - просто прекратите развертывание соответствующей ветки/тега, но если вы используете несколько версий, вы можете получить действительно запутанную структуру ветвей и развертывание трубопровод. Модель "унифицированная кодовая база" позволяет избежать этой проблемы, но (я думаю?) Было бы намного сложнее удалить устаревшие ресурсы и конечные точки из кодовой базы, когда они больше не требуются. Я знаю, что это, вероятно, субъективно, потому что вряд ли будет простой правильный ответ, но мне любопытно понять, как решить эту проблему организации, которые поддерживают сложные API-интерфейсы в нескольких версиях.