# 13. Версионирование API
# 13.1 Введение
Когда вы напишите ваше замечательное новое API, вскоре может понадобиться в нем заменить старый или добавить новый функционал. К сожалению, нет никакого консенсуса какой подход для решения такой задачи будет лучшим.
Основной совет, который вы получите от экспертов звучит так: Постарайтесь ограничиться в изменениях API настолько, насколько это возможно. И это очень справедливое утверждение, но оно также немного похоже на отговорку. Независимо от того, насколько хорошо бы не было спланировано ваше API и ваши бизнес требования, скорее всего не получится следовать такому совету.
Особенно в мире стартапов, где все менее структурировано. Все начинается с "Opportunities (возможностей)", которые превращаются в "Photo Opps (фото отчет)" и заканчивается все это так называемыми "Campaigns (кампаниями)". Вы можете смеяться, и говорить что это с вами никогда не случится, но всеже это случится. Когда вы будете меньше всего этого ожидать, к вам придут бизнес-требования и как скумбрия мокрым хвостом ударят по лицу. Когда это случится, версионирование API ваше единственное решение.
> Конечно, вы можете сказать, что выше API должно поддерживать обратную совместимость - но это не очень реально, когда ваш API должным образом используется на всей линейке продуктов. Чтобы продемонстрировать дальше, предположим, что у вас есть 30 приложений (и возможно горстка внешних компаний, использующих API), каждое из которых опирается на "клиентский" REST ресурс - тогда вы можете выбрать следующее:
>
> 1. Сохранять обратную совместимость (и потерять продаж на 1млн. долларов, потомучто вы не можете реализовать крутую функцию "X")
> 2. Внести изменения во все 30 приложений одновременно для обработки новых данных (но вам, вероятно, не хватит ресурсов чтобы сделать это вовремя и в срок)
> 3. Сделайте изменения, нарушив работу приложений, но получите продажи (конечно вы можете исправить оставшиеся приложения в будущем, правильно?)
> **Источник**: [thereisnorightway.blogspot.com.tr](http://thereisnorightway.blogspot.com.tr/2011/02/versioning-and-types-in-resthttp-api.html)
## 13.2 Различные подходы в версионировании API
Как это было сделано в нескольких других главах, в этой главе будут изложены несколько различных подходов и перечислены их плюсы и минусы. В других главах как правило есть предложение, которое является "лучшим" решением, но в этой главе не так, и между ними есть компромиссы. Некоторые технически и являются RESTfull, но невероятно сложны в реализации и также сложны для использования вашими пользователями. Это означает, что при выборе подхода придется хорошенько пораскинуть мозгами.
На протяжении всей главы будут отсылки на различные популярные сервисы с публичным API и типами используемой версионности. Спасибо Тиму (Tim Wood) за составление обширного списка [“How are REST APIs versioned?”](http://www.lexicalscope.com/blog/2012/03/12/how-are-rest-apis-versioned/), на который буду часто ссылаться в этой главе.
This file has been truncated. show original