Si dovrebbe generalmente sviluppare una libreria client per i servizi REST per aiutare a prevenire le rotture API?

Question

Si dovrebbe generalmente sviluppare una libreria client per i servizi REST per aiutare a prevenire le rotture API?

#1 da (1 voti)
#2 da (1 voti)
#3 da (1 voti)

9

Abbiamo un progetto in cui il codice UI sarà sviluppato dalla stessa squadra ma in una lingua diversa (Python / Django) dal livello dei servizi (REST / Java). Il codice per ogni livello termina in diversi repository di codice e può seguire diversi cicli di rilascio. Sto cercando di elaborare un processo che impedisca / riduca le modifiche di rottura nel livello dei servizi dal punto di vista del livello dell'interfaccia utente.

Ho pensato di scrivere test di integrazione a livello di livello dell'interfaccia utente che verranno eseguiti ogni volta che creeremo l'interfaccia utente o il livello dei servizi (utilizzeremo Jenkins come strumento CI per creare il codice che si trova in due repository Git ) e se ci sono errori allora qualcosa nel livello dei servizi si è rotto e il commit non è accettato.

Sarebbe anche una buona idea (è una buona pratica?) che lo sviluppatore del livello di servizi crei e gestisca una libreria client per il servizio REST esistente nel livello dell'interfaccia utente che aggiornerà ogni volta che c'è un rompere i cambiamenti nella loro API di servizio? In teoria, avremmo il vantaggio di un'API tipicamente statica contro cui si basa il codice UI. Se l'API della libreria client cambia, allora il codice UI non verrà compilato (quindi sapremo presto che c'è stata una violazione). Continuerò anche a eseguire i test di integrazione sulla costruzione dell'interfaccia utente o del livello di servizi per verificare ulteriormente che l'integrazione tra l'interfaccia utente e i servizi continui a funzionare.

rest django

posta BestPractices 06.08.2012 - 03:36

fonte

3 risposte

Leggi altre domande sui tag rest django

Nome del problema round Countdown Numbers - e soluzioni algoritmiche? Dopo aver infranto il nostro codice in bit riusabili, come testiamo e implementiamo?

score 1 · Answer 1

In generale, per i metodi dell'API che vanno via, scegli una convenzione e "deprecati", soprattutto non appena è disponibile e testata un'API completa di sostituzione. Lascia la vecchia API in posizione (essenzialmente), ma tagga i metadati della firma del metodo o inserisci un evento di registrazione in modo che l'utilizzo possa essere chiaramente identificato.

La registrazione all'interno dell'API del servizio è una cosa, ma avvisare i consumatori che consumano è un'altra. Per REST, non penso ci sia una pratica solida e standard. I client FourSquare API possono scoprire metodi deprecati anche se il metodo chiamato ha esito positivo (codice HTTP 200, tuttavia errorType verrà impostato su 'deprecato'). Forse una strategia ragionevole per fornire ai consumatori che consumano l'opportunità di conoscere un metodo deprecato all'interno dell'API senza causare problemi.

link

All'interno della guida API, suggerire una data o creare il numero di rilascio in cui l'API deprecata verrà rimossa completamente. Come tu definisci la tua strategia per la deprecazione, dovrai avvisare i consumatori dell'API su quale sia la strategia proposta (come possono scoprire metodi deprecati, come passare all'API di sostituzione e quando l'API deprecata non sarà più disponibile se eliminati durante una pulizia dell'API) e sollecitare feedback da parte loro per garantire che il processo sia soddisfacente per tutti.

score 1 · Answer 2

La versione della tua API è un'altra possibilità. Quando viene distribuita una nuova versione, lasciare attiva anche la versione precedente e consentire la negoziazione tramite la richiesta. Se mantieni le versioni 2 o 3 più recenti, il codice UI può aggiornarsi secondo il proprio ritmo.

score 1 · Answer 3

Ci sono almeno tre domande contemporaneamente, facciamole una alla volta

"è una buona idea avere una libreria client per il servizio REST?"

Molto probabilmente sì, a patto di non volere chiamate REST arbitrarie direttamente sparse attraverso tutto il codice dell'interfaccia utente.

"è una buona idea lasciare che lo sviluppatore del livello di servizi crei e gestisca la lib?"

Dipende dalle persone della tua squadra. Il manutentore dell'API dovrebbe conoscere sia le cose disponibili nel livello dei servizi sia i requisiti del livello dell'interfaccia utente. Quindi può essere una persona dal livello servizi o uno dal livello dell'interfaccia utente o (a seconda delle dimensioni e di altre attività) una persona indipendentemente da entrambi i team.

[otterremo un vantaggio dal fatto che] "se l'API della libreria client cambia, allora il codice UI non verrà compilato"

Non avevi detto che l'interfaccia utente sarebbe stata scritta in Python? Non è un linguaggio tipizzato in modo statico, quindi non mi aspetto una interruzione immediata della build da una modifica dell'API. Suppongo di averti sbagliato a questo punto e qui hai un'API tipicamente staticamente - quindi potresti ottenere alcuni vantaggi finché la build non si interrompe aggiungendo alcune nuove funzionalità (come i nuovi parametri facoltativi) all'API. Altrimenti produrrà un sovraccarico inutile sulla tua squadra.