Come concretizziamo l’approccio API First attraverso le linee guida e APIOps

In Intesys, il nostro obiettivo è aiutare le aziende a sfruttare al massimo il potenziale delle API, riconoscendone il ruolo di pilastro delle architetture IT moderne.
Il nostro approccio è sempre stato sistemico: le competenze, l’esperienza e i tool di cui disponiamo vengono messi al servizio dei clienti non solo per fornire delle risposte concrete a esigenze specifiche, ma anche per favorire la loro evoluzione verso le migliori pratiche, verso i processi e i paradigmi più moderni di sviluppo e di gestione del ciclo di vita delle API.
In questo percorso evolutivo, le API guidelines, APIOps e API linting – che affronteremo in un approfondimento successivo – non  sono soltanto temi fortemente connessi, bensì dei fattori abilitanti di un nuovo modo, più efficiente, automatizzato e moderno, di creare, gestire e governare le API. Vediamo in dettaglio di cosa si tratta.

API guidelines a beneficio della centralità degli sviluppatori

Per prima cosa, in Intesys promuoviamo una visione fondata sulla centralità dello sviluppatore, in quanto principale consumatore delle API e, di conseguenza, motore dell’innovazione aziendale.

Mettere lo sviluppatore al centro significa fornirgli gli strumenti che gli permettano di concentrarsi sull’innovazione, riducendo al minimo le attività ripetitive, lo studio e la gestione degli errori. Affinché ciò sia possibile, è fondamentale che le API siano progettate in modo strutturato e coerente fin dall’inizio, così da permettergli di lavorare velocemente ma non di fretta, ovvero in modo organizzato, efficace e veloce.

Qui emerge, per la prima volta, la necessità che l’azienda definisca delle precise linee guida per il design e lo sviluppo delle proprie API (API guidelines), ovvero delle convenzioni, delle regole e degli standard che garantiscano coerenza, scalabilità e manutenibilità a tutte le API esposte dai sistemi aziendali. La presenza di guidelines rende di fatto più facile e veloce l’integrazione dei servizi esposti a tutte le classi di utilizzatori, dagli sviluppatori interni ai partner e ai fornitori.

Dall’approccio decentralizzato ad APIOps

Dotarsi di linee guida per la progettazione e lo sviluppo delle API è una considerazione di puro buon senso. Tuttavia, tra la teoria e la pratica c’è ancora parecchia distanza.

Gli approcci API: decentralizzato e centralizzato

Molte realtà complesse e strutturate adottano infatti un approccio decentralizzato. Le API vengono sviluppate e pubblicate da diversi DevTeam che operano a silos, che non collaborano e, soprattutto, che non seguono degli standard vincolanti imposti dall’azienda.

L’approccio intermedio, che definiamo centralizzato, è sicuramente un passo avanti. In questo caso esistono delle API guidelines vincolanti e ogni team, pur lavorando in modo indipendente, è vincolato a rispettarle: il risultato è ottimale dal punto di vista qualitativo, ma manca del tutto un supporto da parte di meccanismi e strumenti di automazione. Il time to market, ovviamente, ne risente.

Obiettivo: APIOps

Il modello che adottiamo e promuoviamo è APIOps, che applica i principi DevOps all’intero ciclo di vita delle API. Questo approccio non si limita a definire delle guidelines per la progettazione e lo sviluppo delle API, ma integra degli strumenti di automazione (test) finalizzati a garantire che le API rispettino tali standard in ogni fase. In questo modo si eliminano i colli di bottiglia tipici dei modelli tradizionali, migliorando la velocità e l’affidabilità dei processi di sviluppo e di rilascio delle API.

I consumer delle API, che restano al centro dell’attenzione, possono a questo punto contare su un insieme di API coerente, standardizzato, sempre aggiornato e ben documentato.

Adottare un modello APIOps, inoltre, non significa solo avvalersi di strumenti di test che verificano in forma automatizzata la rispondenza delle API alle linee guida, ma anche poter anticipare (shift left) questi test (che solitamente si eseguono nelle fasi di deploy o di build) alla primissima fase del ciclo di vita delle API, ovvero al design.