Negli ultimi anni con una progressiva “cloudificazione” molte aziende sono passate a sviluppare i propri prodotti come SaaS, questo processo ha dato vita a quella che è diventata nota come API Economy, ma innanzitutto …

Cos’è un’API?

Le API, abbreviazione di Application Programming Interface, sono le interfacce per accedere alle funzionalità esposte da un determinato software e la definizione di come interagire con esse (quali richieste fare e come farle, il formato da utilizzare ed i risultati previsti).

Un’API può essere:

  • Interamente personalizzata
  • Specifica per un componente
  • Progettata sulla base di uno standard industriale in modo da garantire l’interoperabilità tra software.

Ci sono molti tipi di API, ma le più comuni (e quelle su cui si concentra questo articolo) sono le  Web API (accessibili attraverso il protocollo HTTP/S ).

Altre forme di API possono essere quelle fornite da una libreria software o da un sistema operativo.

L’evoluzione dell’API Economy

Prima dell’avvento dell’API Economy, e della “necessità” di esporre le funzionalità a UI web-based, il modo più comune per accedere al contenuto di un servizio di terze parti (che aveva una UI web) era quello di utilizzare una tecnica chiamata Web scraping.

Il Web scraping consiste nel processo di scaricare il contenuto di una pagina web (sotto forma di codice sorgente) ed estrarne (fare “scraping”) le informazioni richieste.

Questo processo tuttavia può essere difficile (a causa delle restrizioni imposte da un sito web o della necessità di autenticarsi per accedere a determinate pagine) e soggetto ad errori (poiché anche piccoli cambiamenti nella grafica di una pagina possono rendere le informazioni non più disponibili o più difficili da estrarre) oltre che essere stato per lungo tempo considerato anche illegale.

E allora quando le aziende hanno iniziato a rendersi conto delle potenzialità di offrire i propri servizi in modo più ampio e consentire l’integrazione con servizi esterni,

le Web API hanno iniziato a prendere piede .

SOAP, REST e JSON-RPC

Le Web API sono spesso disponibili in diversi stili ma le più comuni sono:

  • SOAP (Simple Object Access Protocol) è uno dei primi protocolli progettati per permettere ad applicazioni o servizi diversi di condividere le risorse in modo sistematico attraverso l’uso di connessioni di rete. Anche se il nome implica la semplicità d’uso, si basa su lunghi schemi XML e definizioni che lo rendono un po’ pesante e non così facile da gestire.
  • RESTful API (REpresentational State Transfer) che consiste nel modellare un’API basata sulle risorse che espone (ad esempio utenti, ordini, ecc.) e permettendo operazioni su di esse utilizzando diversi verbi HTTP (GET per recuperare una o più istanze, POST per crearne di nuove, PUT per aggiornarle, DELETE per rimuoverle e altro ancora a seconda della risorsa), e utilizza JSON (JavaScript Object Notation) come formato di trasferimento dati (può essere usato anche il formato XML, ma è meno comune).  Ad esempio per recuperare una lista degli utenti di una piattaforma avrei un endpoint API come GET /users, per crearne uno nuovo chiamerei POST /users, ecc…
  • Le API JSON-RPC (JSON Remote Procedure Call) consistono invece nel modellare un’API basandosi sulle operazioni esposte (ad es. createUser, createOrder, ecc.), utilizza al massimo due verbi HTTP (GET e POST) e definisce il formato di trasferimento dati in JSON. Ad esempio, come sopra, per recuperare una lista degli utenti chiamerei un GET /listUser, per creare un nuovo utente chiamerei POST /createUser, ecc…

Nonostante API di questo tipo sono semplici da usare e molto diffuse, nel tempo hanno iniziato a mostrare anche qualche difetto, soprattutto a causa della grande quantità di dati che vengono trasferiti man mano che i servizi diventano più popolari, tra cui i principali sono:

  • L’ overfetching (si ricevono più dati di quelli necessari e le chiamate per recuperarli diventano quindi più lente)
  • L’ underfetching (si ricevono meno dati di quelli necessari e si devono fare più richieste ed implementare logiche per riconciliare i diversi risultati – si pensi al recupero di tutti gli ordini effettuati da un insieme di utenti).

Nuovi modi di sviluppare WEB API: GraphQL e Falcor

Le grandi Data Company hanno affrontato questi problemi sin da subito ed hanno quindi dovuto studiare nuovi modi di sviluppare Web API:

GraphQL di Facebook e Falcor di Netflix.

Entrambi inizialmente utilizzati internamente alle due Aziende sono stati successivamente rilasciati al pubblico.

Se Falcor non ha ottenuto grande successo, GraphQL ha invece guadagnato molto terreno diventando rapidamente una delle tecnologie più apprezzate per sviluppare nuove API.

Cosa rende GraphQL diverso?

GraphQL permette una grande flessibilità quando si interagisce con una API,  un client ha un solo endpoint da interrogare (solitamente /graphql), facendo richieste in forma di query RPC e può specificare esattamente quali dati recuperare utilizzando una richiesta formattata in JSON.

Queste caratteristiche rendono GraphQL molto adatto ad essere utilizzato da molti tipi diversi di client siano essi ambienti web, mobili o senza UI (si pensi alla differenza tra i dati mostrati in una pagina web e quelli mostrati su un’applicazione mobile o addirittura a quelli pronunciati da un assistente virtuale), mantenendo ridotti tempi di risposta e garantendo facilità d’uso agli sviluppatori.