Il passaggio alle applicazioni cloud-native e in generale la diffusione dei microservizi ha portato le API alla ribalta. Tutti ne parlano ed è anche nata l'espressione API economy per evidenziare la nascita di un vero e proprio modello di business basato sulle API, ossia su servizi di terze parti che gli sviluppatori possono invocare per realizzare nuove applicazioni. Invece di sviluppare tutto da zero, si ragiona anche in questo campo in una ottica di componenti software riutilizzabili, stavolta distribuiti.

Non è l'unico mercato che si sta sviluppando più velocemente di prima: c'è anche quello delle soluzioni di API management, che aiutano a tenere traccia delle potenzialmente decine e centinaia di API usate dal complesso delle nostre applicazioni aziendali. Chi abbia approcciato anche un minimo lo sviluppo software sa bene che le Application Programming Interface esistono da decenni e non sono certo nate con il cloud. Per tutti gli altri, è utile familiarizzare con i loro concetti base, per come si sono adattati allo sviluppo odierno.

In estrema sintesi, una API delinea in che modo un qualsiasi componente software interagisce con l'esterno, quindi con altri software. Nel caso di un microservizio, indica in che modo le sue funzioni possono essere richiamate da altri servizi o applicazioni. Come queste funzioni siano implementate resta "nascosto" a chi le richiama. Se ad esempio stiamo creando un modulo per postare su Twitter, non ci interessa sapere come funziona "dentro" il social network. Ci basta avere accesso a un'API che indica quali funzioni richiamare per caricare un post, quali dati passare loro e in che formato e sequenza.
Nello sviluppo software le API hanno sempre funzionato in questo modo. Sono i "connettori" di un servizio verso l'esterno e permettono a chi lo usa di astrarsi dal suo funzionamento. Grazie a questo approccio chi sviluppa un servizio può modificare il suo codice come e quando vuole, basta che le API non cambino. Sembra banale ma non lo è, perché un disallineamento tra API e codice "interno" di un servizio può provocare grossi problemi.

Rispetto al modello generico di una Application Programming Interface, nel mondo del cloud una API è sempre basata sui protocolli tipici del web. Ciò significa in linea di principio che si interagisce con essa attraverso richieste HTTP, come un web browser, e che i dati vengono passati all'API e da essa ricevuti in formato JSON (JavaScript Object Notation, un formato che per semplicità possiamo considerare analogo a XML). Una delle conseguenze di tutto questo è che un servizio deve essere identificato da una URL a cui accedere via HTTP. Per proseguire con il nostro esempio sull'API di Twitter, la timeline di un utente è un oggetto JSON che si "contatta" all'URL https://api.twitter.com/1.1/statuses/home_timeline.json.

La quasi totalità delle API legate allo sviluppo cloud è RESTful, un altro termine che si incontra assai di frequente. Una API RESTful è sviluppata secondo il modello architetturale Representational State Transfer (appunto REST). La definizione vuol dire tecnicamente molte cose, ma l'elemento che interessa di più chi vuole comprendere la dinamica dei microservice è che questi sono a priori stateless: non conservano alcuna informazione riguardante l'oggetto (un'applicazione o un altro servizio) che li contatta.

Se ci si pensa, è logico: per garantire flessibilità e coerenza di funzionamento, un microservizio deve essere "agnostico" in merito a cosa lo contatterò, quando e come. Basta che rispetti la sua API.
Operare in maniera stateless non è una condizione sempre ottimale e infatti ci sono modi per conservare lo stato delle interazioni tra microservizio e client, modi che però introducono complessità architetturali. Caso per caso, si giudica se queste siano accettabili o meno, in funzione dei vantaggi che portano.

Nella creazione delle API gli sviluppatori hanno infatti una buona libertà di movimento: esistono certamente modelli preferenziali e best practice, ma non esiste "il" modo per sviluppare le API. Per fare un esempio, non è detto che il diffusissimo formato JSON sia adatto sempre e comunque. Questa elasticità è positiva, perché gli sviluppatori possono creare le API più indicate alle specifiche necessità di chi deve usare un microservizio.

C'è ovviamente un altro lato della medaglia. Questa libertà di sviluppo fa sì che ci siano API ben progettate e altre meno. Quando si parla di API design si intende proprio questo: una API dovrebbe essere non solo scritta correttamente ma anche in modo da facilitare il compito di chi deve usarla. Dovrebbe quindi essere pensata sin dall'inizio tenendo conto del modo in cui (e degli scopi per cui) più probabilmente gli altri sviluppatori la useranno. Una API che non rispetta questi requisiti è più difficile da usare e ciò aumenta la probabilità di errori nella scrittura del codice o nella logica dell'applicazione.