В интернете по поводу управления версиями апи в основном предлагается подход, при котором в одном проекте сосуществуют контроллеры из нескольких версий. Т.е. например HelloWorldControllerV1 и HelloWorldControllerV2. И апи будет переключаться между ними в зависимости от того, хэдер с запросом на какую версию пришел. Т.е. по-сути каша из контроллеров разных версий.
Хотелось-бы все-же иметь один проект, но с управлением версиями (в хэдерах). Можно-ли этого как-то достичь? Т.е. к примеру стоит у клиента версия v1, там есть путь /myservice/helloworld. Разработали новую v2 версию, и клиент теперь может по тому-же пути /myservice/helloworld получить либо первую версию либо вторую в зависимости от того, что запросил в хэдере?

hVosttСовершенно точно так делать не нужно. Это нарушение концепции HTTP, что ни приведёт ни к чему хорошему. У каждой версии API должен быть отдельный URL.
нарушение концепции HTTP как раз вложение версий в урлы. Хотя это самый простой для разработки метод, но и самый неудобный для клиентов так как им придется переписывать конфиги с выпуском каждой новой версии
Еще вопрос, у кого-нибудь есть практический опыт реализации версионности "стандартным" методом, когда в одном проекте сосуществуют множество версий контроллеров? Именно такой подход настойчиво советует Майкрософт, но на первый взгляд он кажется крайне неудобным, кто-нибудь делал такие проекты, какие там подводные камни лежат на практике?

handmadeFromRuто что ТС можно сделать без проблем, но надо идти по простому и очевидному
новое апи часто меняет методы, а не просто внутри переписывает и другое дто возвращает
те методы что не изменились все равно оказываются с другим адресом в новой версии. Так наказывать своих клиентов не выглядит привлекательно