Как стать автором
Обновить

Комментарии 4

А что предлагается делать с мобильными приложениями, например?) Их нельзя просто взять и развернуть — гугл или яблоко спокойно могут отправить новую версию на недельное ревью без всякого предупреждения и возможности ускорить процесс.

К тому же, а если в компании произошла резкая ротация фронтендеров — как работать с недокументированным апи в таком случае? Новый человек, не знающий исторического контекста потратит уйму времени на вникание. А рано или поздно любой малый проект оказывается в такой ситуации.
Тут разговор о том, что если у вас один потребитель, который в вашей власти — то это не «классический» API. Документировать его надо не для «внешних» пользователей, а для своих же разработчиков. И менять можно, не очень опасаясь обратной совместимости. Да, можно держать две версии, но потом одну выкинуть без опаски, что клиент сломается.
Как API не назови, а он все равно останется API. И неважно, будет он между сервером и клиентом, двумя серверами или двумя модулями… Отсутствие желания его документировать, делать его простым и удобным или поддерживать для использования на стороне всё ещё не превращает его из API во что-то другое, а просто делает его «плохим» API. Но он всё равно остается интерфейсом и всё равно программным.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий