Как присвоить версию REST URIs
Да, вам нужно будет сделать git fetch или git fetch origin в этом случае. Git не волнует, куда вы нажимаете, только удаленные (и удаленные ветви отслеживания) - это все, что имеет значение, когда вы сообщаете о состоянии того, сколько коммитов вы впереди и т. Д.
5 ответов
Я бы сказал, что лучше всего сделать его частью самого URI (вариант 1), потому что v4 идентифицирует другой ресурс, чем v3. Параметры запроса, как во втором варианте, лучше всего использовать для передачи дополнительной (запрашиваемой) информации, связанной с запросом , а не с ресурсом .
Эти (менее конкретные) вопросы SO о версиях REST API могут быть полезны:
Я бы добавил версию в качестве необязательного значения в конце URI. Это может быть суффикс, например / V4, или параметр запроса, как вы описали. Вы даже можете перенаправить / V4 на параметр запроса, чтобы поддерживать оба варианта.
Не обновляйте URL-адреса, потому что ...
- вы нарушаете постоянные ссылки
- Изменения URL-адресов будут распространяться через ваш интерфейс как болезнь. Что вы делаете с представлениями, которые не изменились, но указывают на представление, которое изменилось? Если вы измените URL-адрес, вы сломаете старых клиентов. Если вы оставите URL-адрес, ваши новые клиенты могут не работать.
- Управление версиями типов носителей - гораздо более гибкое решение.
Предполагается, что ваш ресурс возвращает некий вариант application / vnd.yourcompany.user + xml, все, что вам нужно необходимо создать поддержку для нового типа носителя application / vnd.yourcompany.userV2 + xml, и с помощью магии согласования содержимого ваши клиенты v1 и v2 могут мирно сосуществовать.
В интерфейсе RESTful, Самое близкое к контракту - это определение типов носителей, которыми обмениваются клиент и сервер.
URL-адреса, которые клиент использует для взаимодействия с сервером, должны предоставляться сервером, встроенным в ранее полученный представления. Единственный URL-адрес, который должен быть известен клиенту, - это корневой URL-адрес интерфейса. Добавление номеров версий к URL-адресам имеет значение только в том случае, если вы создаете URL-адреса на клиенте, что вы не должны делать с интерфейсом RESTful.
Если вам нужно внести изменения в ваши медиа-типы, которые нарушат работу ваших существующих клиентов, тогда создайте новый и оставьте ваши URL в покое!
И для тех читателей, которые сейчас говорят, что это не имеет смысла, если я использую application / xml и application / json в качестве типов носителей. Как мы должны их редактировать? Ты не.
А, я снова надеваю свою старую сварливую шляпу
С точки зрения ReST, это вообще не имеет значения. Не колбаса.
Клиент получает URI, которому он хочет следовать, и рассматривает его как непрозрачную строку. Поместите в него все, что хотите, у клиента нет сведений о такой вещи, как идентификатор версии.
Клиент знает, что он может обрабатывать тип носителя, и я советую следовать совету Даррела. Также я лично считаю, что необходимость 4 раза изменить формат, используемый в спокойной архитектуре, должна вызвать огромные массивные предупреждающие знаки о том, что вы делаете что-то серьезно неправильно, и полностью избавиться от необходимости разрабатывать свой тип носителя для устойчивости к изменениям.
в любом случае клиент может обрабатывать документ только в понятном ему формате и переходить по ссылкам в нем. Он должен знать о связях (переходах). Так что то, что находится в URI, совершенно не имеет значения.
Я лично проголосовал бы за http: // localhost / 3f3405d5-5984-4683-bf26-aca186d21c04
Совершенно допустимый идентификатор, который предотвратит дальнейшее развитие клиента или человек, касающийся системы, чтобы спросить, следует ли ставить v4 в начале или в конце URI (и я предлагаю, с точки зрения сервера, у вас должно быть не 4 версии, а 4 типа носителя).