Pagina 1 di 1
Ho ereditato un'API Laravel usata da 40 integratori terzi senza versioning. Aggiungere un campo obbligatorio era un problema diplomatico prima che tecnico: non potevo rompere i client esistenti, ma neanche bloccare l'evoluzione. La backward compatibility non è un dettaglio: è la differenza tra un'API che evolve e una che muore.
In questa categoria scrivo di backward compatibility applicata: strategie di versioning per API pubbliche (URL path, header, content type), deprecation graduale con header `Sunset` e log dei consumer ancora attivi, comunicazione tecnica con integratori terzi, criteri per breaking change responsabile.
Se hai un'API pubblica che deve evolvere senza rotture, parliamone. Oppure scopri il mio approccio.
Ho ereditato un'API Laravel usata da 40 integratori terzi senza versioning. Aggiungere un campo obbligatorio era un problema diplomatico prima che tecnico. Vi mostro le strategie di versioning che ho adottato, come ho introdotto il versioning retroattivamente e il contratto di deprecation che uso con i clienti API. Continua a leggere
