Дилемма v1 / v2 - это сильный намек на то, что у вас фактически нет REST API для начала.Пиры в архитектуре REST обмениваются более или менее стандартизированным контентом клиентами, запрашивающими представления медиа-типов, которые они понимают.Этот метод называется согласованием типа контента.Конечно, плохо написанный сервер может игнорировать предложенные типы медиа и отправлять тот, который клиент не понимает.Это, однако, предотвратит дальнейшее взаимодействие клиента с сервером.Поэтому сервер с хорошим поведением должен пытаться обслуживать клиентский запрос как можно лучше.
Согласно Филдингу:
API REST должен тратить почти все свои описательные усилия наопределение типа (типов) мультимедиа, используемых для представления ресурсов и управления состоянием приложения, или определение расширенных имен отношений и / или разметки с поддержкой гипертекста для существующих стандартных типов мультимедиа.Любое усилие, затрачиваемое на описание того, какие методы использовать для каких интересующих URI, должно быть полностью определено в рамках правил обработки для типа носителя (и в большинстве случаев уже определено существующими типами носителя).[ Ошибка здесь подразумевает, что внешняя информация управляет взаимодействием вместо гипертекста .]
Источник
Тип носителя описывает, какСинтаксис полезной нагрузки, обмениваемой для такого медиа-типа, выглядит так же, как и семантика каждого элемента в этом представлении.С помощью осмысленных имен отношений ссылок и типов мультимедиа сервер может обучить клиента следующим доступным опциям, которые клиент может использовать при выполнении своей задачи.Т.е. вспомним случай, когда в предыдущем ответе содержалось отношение ссылки create к клиенту.Клиент на самом деле не знает, как что-то должно выглядеть для того, чтобы его можно было обрабатывать на сервере, поэтому при вызове URI, возвращаемого для имени отношения ссылки create, сервер отвечает представлением в виде формы вдоль строки application/vnd.xyz-form+jsonгде этот тип мультимедиа определяет некоторые элементы управления вводом, которые клиент может использовать для генерации представления запроса, ожидаемого сервером на целевой конечной точке.Как и в Интернете, пользовательская форма также содержит действие HTTP, а также целевой URI, предоставленный клиентом для отправки ответа, и в конечном итоге также предпочтительное представление сервера.
Клиенты в архитектуре REST не должны 'насчет URI, поэтому возвращение URI, содержащего v1 или v2, должно быть для них более или менее бессмысленным.Филдинг даже заявил, что сам REST API вообще не должен иметь версию !Что важно, так это то, что клиент и сервер способны понять полученную полезную нагрузку.
Вместо управления версиями URI или API тип носителя, описывающий синтаксис и семантику, фактически должен быть версионирован.То есть, если вы посмотрите на веб-браузер на основе браузера (большой брат REST) и, в частности, на HTML, вы заметите, что он разработан таким образом, чтобы требовать, чтобы новая версия оставалась обратно совместимой.Т.е. клиент и сервер, получающие определенную полезную нагрузку text/html, смогут обрабатывать чистый HTML (1.0) вплоть до содержимого HTML5 независимо от того, какой синтаксис (даже смесь) использовался.Однако другие типы носителей могут быть не такими снисходительными.Здесь вы можете использовать профили или зарегистрировать совершенно новый тип носителя, если считаете, что старый и новый полностью несовместимы друг с другом.
В любом случае, я надеюсь, что смогу пролить немного света наREST архитектура и как вы могли бы туда добраться.Мне хорошо известно, что мое предложение может быть нелегко реализовать, хотя, получив его, вы в основном отделили клиентов от своего API и дали последнему свободу развиваться, не опасаясь взлома клиентов.Связь все еще будет, но и клиент, и сервер будут связываться с типами мультимедиа, а не друг с другом.Перед созданием нового медиа-типа, вероятно, стоит поискать уже существующих