Должна ли новая версия API поддерживать все API старых версий?[Вопрос дизайна] - PullRequest
Новая
       23

Должна ли новая версия API поддерживать все API старых версий?[Вопрос дизайна]

0 голосов
/ 16 ноября 2018

У меня есть набор apis, выставленный на base/api/v1/end-point1, base/api/v1/end-point2, base/api/v1/end-point3 и т. Д. Это в основном v1 apis.

Теперь мы переходим к раскрытию v2 apis.В этой новой версии API мы добавим несколько новых API, реорганизовать некоторые существующие API (v1), а некоторые API останутся неизменными.

Так что мой вопрос заключается в том, чтобы я показал все неизмененные API V1 вv2 также?

Пример:

API V1:

api / v1 / users - остается неизменным

api / v1 / feature1 - изменится

другие конечные точки ...

API V2:

api / v2 / feature1 - переработанная функция

api / v2 / feature2 - недавно добавленные

api / v2 / users - я должен также выставить это?

Я думаю:

Я не должен: потому что он такой же

Я должен: потому что, если он не выставлен, клиенту нужно будет использовать разные версии API(конечные точки) для различных ресурсов.

Что вы делаете?Что ты думаешь?Будем весьма благодарны за любые ссылки на лучшие практические ресурсы.

Дайте мне знать, если этот вопрос не подходит для этой платформы.Я буду рад спросить это в соответствующем месте.

1 Ответ

0 голосов
/ 17 ноября 2018

Да.

Каждая версия должна быть независимой от другой. Смысл в том, что как только версия API публикуется, она будет вести себя так же, пока не станет устаревшей. Это гарантирует, что предоставляемый API стабильный и не нарушает другой ответ. Также с точки зрения конечного разработчика, который использует API, он чистый и не смущает запоминание нескольких версий.

У нас обычно есть несколько версий, как указано в SEMVER docs

Учитывая номер версии MAJOR.MINOR.PATCH, увеличить:

ОСНОВНАЯ версия при несовместимых изменениях API

ОСНОВНАЯ версия, когда вы добавляете функциональность обратно-совместимым способом, и

Версия PATCH, когда вы делаете обратно совместимые исправления ошибок.

...