xoxlobandera: (Default)
just ([personal profile] xoxlobandera) wrote2020-06-02 08:17 pm
Entry tags:

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

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

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

Для меня было контринтуитивным понимание того, что нужно в чем-то ухудшить свой сервис, чтобы в итоге получить улучшение. Но подумав, я понял, что мне известны подобные примеры в индустрии, просто я об этом не задумывался.
dennisgorelik: 2020-06-13 in my home office (Default)

[personal profile] dennisgorelik 2020-06-03 10:04 pm (UTC)(link)
Так ведь если мы рассматриваем ситуацию переключения customer от одного API к другому API, то эти APIs уже разделены.
При этом в Chargebee/Chargeover внесены оба API: и старый и новый.
Ну а если уж мы регистируем в Chargebee/Chargeover старый и новый API по отдельности, то почему бы не назначить разные цены за использование этих различных APIs?
dennisgorelik: 2020-06-13 in my home office (Default)

[personal profile] dennisgorelik 2020-06-04 12:11 pm (UTC)(link)
Да: например XML job feeds.
dennisgorelik: 2020-06-13 in my home office (Default)

[personal profile] dennisgorelik 2020-06-04 01:48 pm (UTC)(link)
> разным функционалом для разных групп пользователей

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