Устаревание API

Устаревание API (deprecation) — это объявление поставщика о том, что эндпоинт, поле, способ аутентификации или целая версия API перестанут работать в названную дату. С места публикующей стороны это уборка. С места всех, кто выстроил на этом интеграцию, это незапланированная инженерная работа со сроком, который назначил кто-то другой, и один из немногих рисков интеграции, который не вероятен, а неизбежен. Первая проблема — как вы об этом узнаёте. Уведомления приходят через журнал изменений, через заголовок, тихо добавленный в ответы, через письмо на адрес, с которого регистрировали приложение, — часто это разработчик, давно уволившийся, — и через баннер в панели, куда никто не заходит после того, как интеграция заработала. Команда может находиться внутри окна отключения месяцами, и первым сигналом станет обращение в поддержку в тот день, когда эндпоинт начнёт возвращать ошибку. Вторая проблема в том, что стоимость миграции редко пропорциональна размеру изменения. Переименовать поле — работа на полдня. Сменить способ аутентификации — значит затронуть каждый сохранённый вами доступ от имени каждого клиента и, как правило, потребовать, чтобы каждый из них нажал кнопку; это уже не правка кода, а проект по коммуникации с клиентами. Отключения к тому же приходят пачками — после поглощения, переписывания платформы или инцидента безопасности, — поэтому допущение, что они равномерно распределятся по году, небезопасно. Практические привычки. Держите опись всех сторонних API, которые вызывает продукт, и версий, которые вызываются: нельзя оценить уведомление об отключении для зависимости, о существовании которой вы не знали. Регистрируйте интеграции на общий адрес, а не на человека. Заносите дату отключения в тот же бэклог, что и собственную дорожную карту, в день объявления, а не за месяц до срока. И считайте обязательство о долгой поддержке отсутствующим, пока оно не записано в договоре: публичная политика устаревания — это заявление о намерениях, которое можно пересмотреть, а не гарантия.