15 Dic The API Lifecycle

Posted at 14:14h in News by

Questo articolo è il continuo di questo primo post, dove abbiamo introdotto le basi per uno sviluppo API-driven (ADD).

Il ciclo di vita delle API coinvolge editori (publisher), manager e “consumatori” nei processi che prevedono la pianificazione la progettazione, l’autenticazione e la creazione delle interfacce API.

Qui invece si discute di un concetto molto rilevante chiamato “ciclo di vita dell’API” e spiegheremo le diverse fasi della vita di un’API e dei diversi “player” che fanno parte di questo ciclo.

Nel life-cycle delle API, esistono tre player principali:

  1. API publisher : crea e distribuisce le API.

  2. API manager : gestisce e monetizza le API.

  3. API consumer : scopre e si integra con le API.

Ognuno di questi attori ha varie attività correlate tra loro che definiscono le vere e proprie caratteristiche delle API (v. Figura 1).

Figura 1

Fig. 1

 

 

Diamo un’occhiata anche al ciclo di vita da un’altra prospettiva  (v. Figura 2) capendo le sue diverse fasi . Qui si può vedere come i vari player affrontano le API nelle diverse fasi.

Figura 2

Fig. 2

L’API manager, l’API publisher, e gli API consumer possono essere rappresentati da persone con diversi compiti all’interno di un’organizzazione.

Nei paragrafi sottostanti, rappresenteremo numericamente i passaggi indicati in Figura 2.

  1. Pianificazione e Strategia
    L’API manager (che potrebbe essere rappresentato da persone con il ruolo di API product manager o API architect) prepara un piano generale su come mostrare le risorse digitali di un’impresa utilizzando API. Il piano può includere l’identificazione dell’elenco delle API, del loro design (compresi i parametri e i tipi), l’ambito di visibilità, ecc. Ultimo ma non meno importante, l’API manager assicura anche che la documentazione dell’API sia completa. C’è un detto popolare nel mondo API: “Un’ API è buona se lo è la sua documentazione”. Quindi la documentazione delle API è uno dei compiti che dovrebbe essere svolto con la massima chiarezza.
  2. Creare, progettare, testare e pubblicare
    Una volta che il piano API è pronto, l’API publisher (che può essere rappresentato da persone con il ruolo di sviluppatore di software o architetto di software) genera API creandole come parte del processo di sviluppo di app core. Il più delle volte, spesso errando, si trovano le responsabilità dell’API manager e dell’API publisher assegnate in modo similare a un IT architect aziendale o a persone designato a fare altro.
  3. Versionamenti
    Ogni API viene sottoposta a ulteriori successive modifiche diverse dalla sua configurazione di progettazione iniziale (ad esempio, i parametri di percorso o di query), variando in base a nuove esigenze. La API viene quindi testata, revisionata e pubblicata in in un DevPortal interno privato dell’impresa. Che un’API sia privata o pubblica, è definito dalle sue impostazioni di visibilità e dalla semantica di governance attorno a essa. Normalmente si vedono i fornitori che utilizzano framework di API come Swagger e gli strumenti che lo circondano svolgere facilmente i compiti sopra descritti.
  4. Features
    L’API manager può applicare più configurazioni di gestione in base alle esigenze dell’organizzazione. Ad esempio, può configurare il limite massimo gratuito di chiamate API e far pagare al all’API consumer tutte le invocation oltre il limite configurato. Può anche configurare reports analitici sull’utiizzo delle varie API e  creare progetti e contratti che possono essere sottoscritti dal consumatore finale. A questo punto, si presume che tutte le API siano pubblicate e disponibili per il consumo, tramite un’applicazione API DevPortal (consultate come esempio Paypal’s API dev portal). Le API possono essere interne o esterne, e allo stesso modo l’API DevPortal può essere un portale pubblico come quelle dell’esempio di PayPal o può essere portale privato accessibile solo da una rete aziendale.

 

I quattro passaggi precedenti, hanno esplorato il ciclo di vita delle API guardandolo dalla prospettiva di un API publisher e di un API manager.

Ora, esploreremo il ciclo di vita delle API dalla prospettiva dell’API consumer, colui che userà queste API . L’API  consumer è di solito uno sviluppatore di applicazioni o un architetto di app che utilizza o integra le API come parte del processo di sviluppo dell’app.

 

5, 6 e 7. Discovery (ricerca), autenticazione e creazione

All’interno del DevPortal API aziendale , il fruitore avrà la possibilità di cercare le API desiderate e di sottoscrivere una particolare API o un piano associato a un gruppo di API come definito dal loro gestore (API manager). L’API  consumer crea un account e registra la propria applicazione per utilizzare le API necessarie. Di solito, viene generato una API key (un codice univoco) per app che viene utilizzato durante il runtime in modo da autenticare l’applicazione che accede all’API stassa. L’utilizzo delle API è l’ultimo passo del suo ciclo di vita. Quando è possibile integrare con successo una API nella propria applicazione e ottenere i risultati desiderati, allora il ciclo è completo.

 

Nota: Alcuni fornitori di gestione API utilizzano un altro ciclo di vita per progettare e promuovere dove le API vengono promosse in diversi forum ai consumatori finali (che sono gli sviluppatori). Non si è toccato questo aspetto del ciclo di vita, poiché potrebbe non essere pertinente dalla prospettiva ADD (API-Driven-Development).

Nel prossimo post di questa serie, parleremo di come ADD è diventato parte di alcune moderne piattaforme di sviluppo di app e vedremo come OneClickApp può essere vincente per fare in modo di gestire tutti gli aspetti del ciclo di vita delle API con una unica piattaforma integrata.

WaveMaker in modo pro attivo integra dalla versione 10.4 la possibilità di integrare direttamente tutte le API con standard OpenAPI 3.0. Il consumer delle API, attraversoWaveMaker, fornisce solamente l’URI delle api rest alla piattaforma, che tramuta queste in codice e le rende da subito pronte per essere utilizzate sulle interfacce HTML5 in modo visuale.