Версионирование APIНаверное, почти все знают и понимают что это такое. А я все равно хочу рассказать подробнее, не зря же я об этом читал в книге Дж. Гивакса «Паттерны проектирования API».
Интересный факт, я заметил, что все используют один и тот же подход версионирования, пихая только его в разные куски, думая, что это и есть разные подходы. А вот и нет, все немного иначе.
Итак, самый известный и почти всеми используемый подход - семантическая строка. Да-да, тот самый паттерн, который включает в себя циферки с точками: 1️⃣.2️⃣.3️⃣
В этой строке обычно три числа:
1️⃣MAJOR – отвечает за мажорные версии, которые обновляются при накате обратно не совместимых изменений
2️⃣MINOR – второе число (минорная версия) отвечает за накат новой обратно совместимой функциональности
3️⃣PATCH – а третье число, которое на самом деле часто не используют - это патчи, то есть обратно совместимые изменения с устранением ошибки или корректировкой поведения работы API.
По сути самое важное при любом обновлении ручки - понять: «А потребители сломаются?». Если ответ на вопрос - «Да», то значит ваше обновление обратно несовместимо и вам нужно поменять мажорную версию. А еще желательно оповестить об этом потребителей, чтобы они своевременно перешли на новую версию и при необходимости старую вывести из эксплуатации.
Как меняются циферки и почему мы разобрались, а теперь давайте перейдем к самому главному и холиварному - куда же нам запихнуть эти цифры?
На самом деле пофиг, я серьезно. Кому-то удобнее в URI прямо в path или в виде параметра, кому-то в Header, а кому-то в отдельное поле Body.
А где вы указываете версию? ❤️ - в строке адреса 🤔 - в заголовке 😱 - в теле
И пишите свои нестандартные варианты, где и как вы использовали семантическую строку. Например, я использую в 🟢🟩🟩🟩🟩🟢, так как это тоже удобно.
