Lessyp,

берём книжку "Building APIs You Won't Hate" и читаем главу "API Versioning", там описано 6 подходов
ну или просто гуглим "API Versioning"

изобретать велосипед-то зачем?

LessypТ.е. к примеру стоит у клиента версия v1, там есть путь /myservice/helloworld. Разработали новую v2 версию, и клиент теперь может по тому-же пути /myservice/helloworld получить либо первую версию либо вторую в зависимости от того, что запросил в хэдере?
Можно, этот подход называется Custom Request Header

hVosttskyANAМожно, этот подход называется Custom Request Header

Таки лично я не советовал бы его использовать. Сложно настраивать и управлять. Практически не работает, когда API меняется путём композиции/декомпозиции методов.
По этому я и предлагаю почитать соответсвующую литературу и статьи для начала.
Всё уже сравнили до нас.

И выбрать более подходящий вариант для своей ситуации.

Также автору подходит вариант Body and Query Params. Используется в Netflix, Google Data, PayPal, Amazon SQS.

А Custom Request Header подход используется, кстати, в Azure

А мы используем передачу номера версии через URI:
https://gethelp.wildapricot.com/en/articles/182#version

handmadeFromRuпередача версии в урл самое имхо удобнее и очевидное
Это самое общепринятое Со своими минусами:
- технически это не RESTful
- от клиента требуются определённые усилия по поддержке актуальности линков

А ТС как раз таки хочет, чтобы клиент не заморачивался с последними.

handmadeFromRuновое апи часто меняет методы, а не просто внутри переписывает и другое дто возвращает
А это тут при чём?

hVosttskyANAА ТС как раз таки хочет, чтобы клиент не заморачивался с последними.

Для этого, как я уже сказал, можно сделать единственную точку (turn server), отвечающую какой API использовать клиенту.

GET: /turn/getapi?app=MyApp&ver=1.11&api=some-api&known-ver=1.0
RESPONSE: https://domain.com/some/api/v1.1

Используем полученный префикс для вызова АПИ. Решает не только задачи версионности.
Можно. Но это потребует переписывания приложений, что уже сейчас пользуются сервисами, что стоят у клиентов ТСа.

Или ты думаешь, что проект только начинается?

LessypЕще вопрос, у кого-нибудь есть практический опыт реализации версионности "стандартным" методом, когда в одном проекте сосуществуют множество версий контроллеров? Именно такой подход настойчиво советует Майкрософт, но на первый взгляд он кажется крайне неудобным, кто-нибудь делал такие проекты, какие там подводные камни лежат на практике?
А дайте ссылку на рекомендацию, если не сложно. Для меня это звучит как бред какой-то.

Выпускается новая версия, ставится на отдельные сервера, старая крутится на старых.
Клиенты постепенно переползают на новую. В итоге старая гасится.

Lessyp,

может Вы поясните нам, а что Вы вообще понимаете под новой/старой версией?

LessypskyANAА дайте ссылку на рекомендацию, если не сложно. Для меня это звучит как бред какой-то.

Выпускается новая версия, ставится на отдельные сервера, старая крутится на старых.
Клиенты постепенно переползают на новую. В итоге старая гасится.

https://docs.microsoft.com/en-us/azure/architecture/best-practices/api-design URI versioning

This versioning mechanism is very simple but depends on the server routing the request to the appropriate endpoint. However, it can become unwieldy as the web API matures through several iterations and the server has to support a number of different versions. Also, from a purist’s point of view, in all cases the client applications are fetching the same data (customer 3), so the URI should not really be different depending on the version. This scheme also complicates implementation of HATEOAS as all links will need to include the version number in their URIs.
...
Media type versioning

This approach is arguably the purest of the versioning mechanisms and lends itself naturally to HATEOAS, which can include the MIME type of related data in resource links.

И где Вы тут увидели про множество версий контроллеров?

the server has to support a number of different versions - это что-ли?

Дак это про то, что на сервере должно быть развёрнуто несколько версий приложения, пока клиенты пользуются и старыми и новыми версиями.

Походу топик родился из-за трудностей перевода

LessypskyANAИ где Вы тут увидели про множество версий контроллеров?

the server has to support a number of different versions - это что-ли?

Дак это про то, что на сервере должно быть развёрнуто несколько версий приложения, пока клиенты пользуются и старыми и новыми версиями.
там описание принципов, реализация тут:

https://github.com/Microsoft/aspnet-api-versioning/wiki/How-to-Version-Your-Service
Принципов чего?

Там написано: "Unfortunately, this causes an issue for service API versioning if you want split the implementation across different types ."

Вы хотите разнести реализацию по разным типам? Зачем?

LessypПотому-что так там написано. В общем как я понимаю опыта в реализации даного подхода у вас нет. Интересует мнение тех, у кого он есть
Данного нет. У нас иначе.