Удаление старой версии API

[xoxlobandera]

Имея старую и новую версии API, когда-нибудь захочется перестать поддерживать старую версию, чтобы уменьшить издержки. Часть клиентов обычно продолжает пользоваться старой версией и не имеет стимулов для перехода на новую версию, поскольку старая версия их всем устраивает.
Решение - создать им стимулы для перехода. Например, добавить задержку (возможно прогрессирующую), или случайно возвращаемый код 500 (возможно прогрессирующий) и т.п. Когда эти клиенты начнут жаловаться, сообщить, что эти проблемы решены в новой версии.

https://blog.ploeh.dk/2020/06/01/retiring-old-service-versions/

Для меня было контринтуитивным понимание того, что нужно в чем-то ухудшить свой сервис, чтобы в итоге получить улучшение. Но подумав, я понял, что мне известны подобные примеры в индустрии, просто я об этом не задумывался.

Comments

[xoxlobandera]

Я примерно так и думал. Когда дорастете до полноценного апи с разным функционалом для разных групп пользователей, тогда будет понятно о чем эта статья и почему автор рассматривал именно эти способы.

[dennisgorelik]

> разным функционалом для разных групп пользователей

У нас каждый XML job feed используется отдельным пользователем.
Этого недостаточно для того, чтобы достичь понимания?

[xoxlobandera]

Нет конечно. Когда у вас функциональность будет побита на модули, разное кол-во которых будет соответствовать разным тарифным планам, а потом вы сделаете новую версию api, а потом захотите старую убрать, и вот тогда сможете попробовать имплементировать свою идею про "всего-лишь добавить новый тарифный план".