API Design: progettare con un approccio outside-in

In un mercato sempre più dinamico e competitivo, le API sono un asset importante per creare valore per il business, favorendo la capacità di un’azienda di accelerare e governare l’innovazione.

Abilitare la propria Architettura IT a rispondere alle richieste del mercato è il risultato di un percorso strategico in cui le API svolgono la funzione di integrare dati e applicativi per connettere non solo le risorse interne all’organizzazione, ma anche quelle esterne (clienti, partner e fornitori).

Maggiore è la capacità di un’azienda di adattarsi al mercato in modo agile, scalabile e veloce, migliore sarà il valore offerto agli utenti e la capacità competitiva futura.
Per questo le risorse tecnologiche devono essere costruite per essere riutilizzabili e in grado di creare agilmente nuovi servizi. Come? Progettando il Design delle API con un approccio user-centered, che esplora i bisogni, i desideri e le esigenze degli utilizzatori per creare delle soluzioni che li soddisfino nel tempo.

Le due prospettive dell’API Design: inside-out e outside-in

Una API può essere disegnata attraverso due approcci: inside-out e outside-in.

Nel primo caso, l’approccio inside-out fa leva sulle strutture presenti, assemblando i servizi già esistenti. Anche se può sembrare la scelta più naturale, le API risultanti sono molto complicate da utilizzare perché viene esposta la complessità insita dei sistemi backend.
I sistemi sottostanti vengono mappati dai livelli superiori, senza però focalizzare l’attenzione su ciò che serve ai consumatori finali.

Riferendosi ad un esempio nel mondo finance, si pensi ad un’architettura informatica che deve integrare applicativi gestionali come il sistema SAP o AS/400: replicare nei livelli superiori i servizi di questi sistemi significa portarsi dietro un bagaglio di complessità come parametri e linguaggi specifici di dominio.

Seguendo questo approccio, non si riesce ad ottenere il massimo vantaggio di una API oriented Architecture multistrato a 3 livelli, dove ogni strato è ben definito e ha una sua responsabilità precisa. Ciò significa che lo strato di Process API è assente o non ottimizzato e non sarà molto efficace il livello di Experience API (per massimizzare le performance del front-end) perché in questo caso esporrà direttamente le logiche dei sistemi di back-end.

Nel caso invece dell’approccio outside-in, la progettazione di una API parte dai bisogni dell’utilizzatore, indipendente dai sistemi sottostanti. In un secondo momento, si fanno poi considerazioni sui sistemi presenti quali formati, connessioni e sistemi di back-end.
Il focus di questo approccio è studiare il Design delle API per renderle il più semplici possibili per chi deve consumarle, ossia intuitive, ben documentate, riutilizzabili e compatibili.

Il risultato sono API che offrono funzionalità in modo generico, adattandosi ad un’ampia gamma di utilizzatori.
Le API pubbliche, per esempio, dovrebbero sempre seguire questo approccio. Si pensi all’applicativo per i pagamenti via intranet “Stripe”, che fornisce API per integrare i sistemi di pagamento favorendo i loro utilizzatori con un design centrato sulle funzionalità desiderate.

API Design: i vantaggi di un approccio outside-in

Mentre l’approccio inside-out è naturalmente più facile e immediato, l’approccio outside-in prevede uno sforzo maggiore nel progettare e implementare le API perché andranno integrate con più sistemi del backend. La criticità sta proprio nell’integrare le API con sistemi che hanno logiche diverse, una terminologia disomogenea, parametri da tradurre e informazioni da mappare.

Per farlo è necessario studiare la progettazione delle API attraverso una fase di Design in cui l’obiettivo è comprendere come, quante e quali API progettare per interrogare i sistemi sottostanti in modo efficiente ed efficace. In questa fase è fondamentale costruire un glossario di termini per definire un linguaggio univoco a tutte le API, definire le relazioni tra le entità, mappare e documentare il tutto per dare omogeneità.

A tale scopo, il paradigma API first prevede l’utilizzo di un linguaggio di definizione standard delle API (come ad esempio Swagger/OpenAPI), che consente di strutturarle, definirle e descriverle per consentire la chiamata di terzi nel momento in cui vengono pubblicate.

Se con l’approccio outside-in l’investimento e lo sforzo iniziale è maggiore, i vantaggi saranno poi nel lungo termine, quali:

• API user-centered a servizio delle esigenze degli utilizzatori (clienti, partner e fornitori).
• Manutenibilità delle API, grazie ad un’evoluzione lineare e semplice nel tempo.
• Velocità di implementazione di nuovi servizi.

Scopri di più sulle API Architecture