Версионирование API в ASP.Net Core

Очень похоже на то что мы используем для Java. Есть enum с набором версий

@ApiVersionList
public enum RestApiVersion {
    v1_0,
    /* initial version */
    v2_0,
    /* - add new endpoint (DtoV1x0) */
    v3_0,
    /* - change endpoint (DtoV2x0) */
}

А в котроллерах методы с аннотациями

@Service
public class ExampleController {

    @GetMapping("/isalive/check")
    public static boolean isAlive() {
        return true;
    }
  
    @ApiVersion(value = "v2_0", deleted = "v3_0")
    @GetMapping("/someService")
    public static DtoV2x0 getDtoV2() {
        return null;
    }
   
    @ApiVersion("v3_0")
    @GetMapping("/someService")
    public static DtoV3x0 getDtoV3() {
        return null;
    }  

}

isAlive - без аннотации - есть во всех версиях

getDtoV2 только во 2

getDtoV3 только с 3 и далее

Дальше annotation processor сгенерирует три реальных контроллера, каждый со своим набором методов.

Версии методов и DTO могут быть любые, но для удобства мы их синхронизируем с версией API где они появились впервые.

До боли напоминает массу сущиствующих туторов, в том числе из msdn. В чем новизна конкретно этого howto?

Как быть с post/put ендпойнтами, если в новой версии v2 нужно внести изменения в схему БД? Допустим, в v2 приложения добавили новое not null поле в схему таблицы, и значение должно выбираться осознанно (не дефолтное), которое будет влиять на остальной процесс бизнес логики.

Вот за что я ненавижу "туториалы" (написание верное), так это за то, что никто не трудится объяснить фундаментальные вещи. Вот что такое синтаксис:

[Route("api/v{version:apiVersion}/[controller]")] [ApiController] [ApiVersion("2.0")]

Что это за магия "version:apiVersion"? Как она работает? Как мне сделать "{something:somethingElse}"? Я должен слепо верить что-ли?

То, что можно сделать контроллер на v2 коню понятно. Так все делают. А вот почему надо именно тот пакет юзаьть? Чем оно лучше просто тупо второго контроллера на v2?

Непонятно как у вас два класса с одинаковым названием WeatherForecastController в дефолтном namespace, пусть и в разных папках, не вызвали ошибки компиляции о том, что такой класс уже существует.