Казалось бы, все разработчики знают, что существуют разные операционные системы, устройства, версии. Однако пользователь версии X.Y не «слышит» пользователя X.0, как это было у Telegram. И рядовой пользователь не хочет и не будет разбираться, почему такое происходит, и сделает лишь одно действие, чтобы исправить это — обновится до последней актуальной версии на своём устройстве. Если не получилось — забьёт и пойдёт к конкуренту. Так уходят в другие мессенджеры или даже меняют PlayStation на Xbox.
Пользователь API редко может "уйти" к конкуренту, особенно, если это внутренний API. При этом может активно возмущаться и эскалировать проблему.
При обновлениях важно так обновиться, чтобы никто не заметил. Для этого и рассмотрим стратегии:
- Обратная совместимость (Backward Compatibility)
- Нумерация версий
- Контролируемое устаревание (Deprecation)
- Content negotiation — способ клиенту и серверу «договориться» об API
Обратная совместимость
Обратная совместимость (backward compatibility) — это способность новой версии API работать со старыми клиентами без необходимости их изменения.
Это первая из стратегий, которая позволяет минимизировать негативное влияние (нулевое — ничего не делать). Делай изменения так, чтобы клиентская сторона продолжала работать без необходимости вносить правки.
Oracle Java — пример IT, где помнят в каждом релизе об обратной совместимости API/ABI уже больше 30 лет
В материале я подсветил, что даже ускорение API может быть критическим изменением. Поэтому важно проверять изменения.
А теперь переходим к изменениям, которые менее вероятно приведут к сбоям.