REST API Versioning in C # Web Api

Question

REST API Versioning in C # Web Api

#1 da (2 voti)

3

Non ho davvero trovato un modo decente / a prova di futuro per i metodi di versione nella mia WebAPI. Questo è quello che faccio di solito ora, ma può diventare confuso e difficile da rintracciare se diventa un po 'grande (finirò con [OBSOLETE] -ing i più vecchi col passare del tempo). Qualcuno ha trovato un'opzione più elegante o gestibile per la versione di WebAPI in C # / NET.

public class CoreController : ApiController    {
    [HttpGet][Route("~/services/core/test/v{_version}")]
    public IHttpActionResult returnTest(int _version) {
        try { 
            switch (_version) {
                case 2:
                    return Ok(returnTest_v2());
                case 1:
                default:
                    return Ok(returnTest_v1());
            }
        } catch { return NotFound(); }
    }
    public string returnTest_v1() { return "SAMPLE_V1"; }
    public string returnTest_v2() { return "SAMPLE_V2"; }
}

c#

posta Jason 12.04.2016 - 15:58

fonte

1 risposta

Leggi altre domande sui tag c#

Pattern di repository e Iniezione di dipendenza senza un ORM Gestione di un database di sviluppo in un progetto di gruppo

score 2 · Accepted Answer

In realtà, dal momento che stai già utilizzando percorsi personalizzati, questa è una soluzione piuttosto semplice. Ha a che fare con la struttura del percorso, che al momento non è perfetta, ma possiamo aggiustarlo.

dal codice di esempio, ritengo che la tua API segua questo modello:

{category}/{resource}/{id}/v{ersion}

Che va bene, il problema è la creazione di quei rami nel codice che non riesco a immaginare sono molto divertenti da mantenere o aggiungere, anche se dovrò ammettere che sarebbe comodo avere il codice della versione precedente a destra lì.

Ad ogni modo, prendi in considerazione alcune cose per farlo:

v{ersion}/{category}/{resource}/{id}

e separa i metodi in ciascuna rotta da solo. Quindi la firma del metodo di esempio diventerebbe:

[HttpGet][Route("~/v1/services/core/test/")]
public IHttpActionResult returnTestv1() { //Remember each method has to be uniquely named in ASP.NET

[HttpGet][Route("~/v2/services/core/test/")]
public IHttpActionResult returnTestv2() {

Noterai che anch'io non li ho usati come variabili, per "infornare" la loro identità. Quindi, mentre questo raddoppia (triplica, quadrupla ...) il numero di metodi per ciascun endpoint, ci sono alcuni aspetti positivi:

1) Compatibilità - Supponiamo che tu rendi questa un'API pubblica. Scrivo qualcosa per la v1, posso continuare a utilizzare v1 fino a quando non lo prendi (la mia azienda, ad esempio, mantiene v4 e v5 e ritirato v3 e precedenti. Blizzard supporta ancora la loro v1 originale dell'API di Warcraft ed è ora in v3 o qualcosa). Ciò significa anche che è possibile modificare chiaramente la funzionalità di determinati endpoint tra le versioni e non confondere i programmi client esistenti. So che in una API SIS ho programmato contro una volta, la funzione di GET / studente / {id} è cambiata drasticamente tra la v1 e la v2.

2) Mantenimento - Con questa nuova struttura, non è possibile confondere dove si sta verificando un errore. Meglio, se decidi di aggiungere solo una modifica all'output o una logica in entrata, puoi comunque chiamare il vecchio metodo e mantenere le cose sempre coerenti.