Se vuoi mescolare v1 e v2 in una base di codice corrente avresti bisogno di avere una ragione per questo. In genere, ciò significa che stai inviando le chiamate del metodo di versione precedente dal tuo servizio API a nuovi "metodi dell'oggetto business", ciò potrebbe comportare alcune conversioni e simili.

Se vuoi mantenere separati i percorsi v1 e v2 verticalmente (i percorsi del codice non condividono nulla) puoi anche permettere che v1 sia servito dalla vecchia (er) versione del tuo software.

Tra la v1 e la v2 prova a raggruppare le modifiche API in modo da poter offrire ai tuoi clienti un documento sulla migrazione. La stabilità dell'API è generalmente apprezzata.

Il tuo esempio è di per sé non-ne vale la pena, è un piccolo cambiamento cosmetico cercare di non farlo. Oppure se li fai entrare di nascosto introducendo altre modifiche più grandi.

Durante l'accatastamento di una nuova interfaccia per la tua v2 potresti offrire loro una sorta di meccanismo di estensione, librerie come OpenGl farlo.

Prova a creare un modello di deprecazione per le tue vecchie superfici API. Supportare tutte le vecchie interfacce fino alla fine dei tempi sarà difficile e molto costoso.

Se possibile prova a mantenere la versione precedente con vecchie distribuzioni del tuo software. Se puoi evitare di non combinare le generazioni di API in una base di codice, fallo.

È molto difficile trovare una buona interfaccia sulla prima incarnazione della superficie dell'API. I clienti potrebbero apprezzarlo, forse puoi evitare la gestione della versione consentendo l'instabilità delle API e interrompendo le modifiche attraverso un ciclo alfa, beta o 0.X.

Ti raccomando di leggere prima il versioning, perché penso che tu abbia frainteso lo scopo del versioning.

Il versioning non riguarda la modifica di un numero ogni volta che si modifica il codice, si tratta di mantenere un modello semantico di numeri relativi al codice, in modo da poter monitorare e tracciare meglio, gestire dipendenze, pianificare release, ecc.

E il miglior schema di versioning che abbia mai visto finora è il Semantic Versioning, o SemVer

Poiché la modifica apportata è a livello API, non dovrebbe influire sul modo in cui il livello aziendale ottiene i post del blog. Basta modificare la convalida dei parametri inviati al livello aziendale. Per illustrare:

//I don't care about this API thing
class BlogService{
   public getBlogs(int count) {
      //...
   }
}

namespace API.V1

class Blogs{
   //...
   public getBlogs(MyParamterClass p) {
     if (p.hasParameter("count") {
         blogs = blogService.getBlogs(p.getParameter("count"));
     } else {
        //Invalid request handling
     }  
   }
}

namespace API.V2

class Blogs extends API.V1.Blogs {
   //...
   public getBlogs(MyParamterClass p) {
     if (p.hasParameter("blog_count") {
       blogs = blogService.getBlogs(p.getParameter("blog_count"));
     } else {
      //Invalid request handling
     }
   }
}