Comments 6
О, зумеры, почти изобрели RDF. Ну наконец-то!
Сама постановка вопроса вызывает легкое недоумение...
Если вы публикуете контракт (API), то потом вы просто не имеете права его менять без обеспечения обратной совместимости. Всегда казалось что это азы разработки.
Даже странно что такой вопрос вообще возникает.
Это как покупаете квартиру у застройщика, живете какое-то время, а потом застройщик приходит и меняет замки на входной двери без предупреждения.
Тут возникают другие вопросы - в каких случаях допустимо менять внутреннюю логику при сохранении контракта, а в каких новую логику нужно добавлять с новым контрактом... Вот это можно обсуждать. Но не изменение опубликованного контракта без сохранения обратной совместимости.
можно и ломать, зависит от проекта. Если это чисто бэк для webа, чего б и не сломать, если деплой обновления будет синхронен
Ну разве что вы все перепоставляете. Такой ситуации как-то на ум не пришло т.к. не сталкивался. Как-то в голове "лежит" некая большая система, где вы меняете какой-то отдельный ее компонент с уже опубликованным ранее контрактом.
а если на этом же апи сидит и мобильный клиент (iOS/android app) - то уже не так просто, т.к. как автор сказал в статье - пользователь не пойдет обновлять аппку по нашему желанию
но вопрос верный
очень много воды и очень мало конкретики... Если я правильно понял - решение предполагает костыль переводящий устаревший язык в современный? Ну такое себе решение...
API без версий — делаем API обратно совместимыми НАВСЕГДА, чтобы позволить бизнесу сотрудничать