API, Web Services e REST

La filosofia delle API arriva da lontano: già nei primi anni ‘90 l’informatica aveva introdotto paradigmi di elaborazione distribuita basati sull’invocazione di API, per fare interagire moduli software dispiegati su differenti server; l’Open Management Group (ente di standardizzazione de facto), ad esempio, aveva prodotto le specifiche di un architettura distribuita (CORBA) che per prima ha promosso la diffusione di questo paradigma.
I principi della SOA (Service Oriented Architecture), l’utilizzo della rete Internet e dei relativi standard hanno successivamente contribuito a promuovere le API come “linguaggio” condiviso attraverso cui un sistema espone funzionalità comuni, anche complesse, sotto forma di servizi, affinché questi siano acceduti ed utilizzati da altri sistemi o servizi, permettendo un arricchimento costante e continuativo di applicazioni.
La concettualizzazione delle API e delle modalità di interazione software tra due sistemi deriva storicamente dall’approccio RPC (Remote Procedure Call). Nel modello RPC due entità (client e server) che debbono interagire utilizzano un protocollo applicativo basato su richiesta/risposta: un client invoca una funzionalità (servizio) sul sistema remoto per ottenere un risultato.
Dal punto di vista del programmatore tale modalità è una estensione della tipica invocazione di una funzionalità presente nelle librerie di supporto (richiamo di una sotto-procedura), con la differenza che l’invocazione in questo caso non è locale all’ambiente in cui il software è eseguito ma, appunto, remoto.
Tutti i modelli RPC richiedono, per poter essere applicati:

  • la definizione formale delle interfacce (metodi) dei servizi offerti;
  • la definizione formale dei parametri, dei data type scambiati e dei valori di ritorno.

Queste caratteristiche sono facilmente individuabili in un Web Services SOAP, che rappresentava fino qualche tempo fa il modello di riferimento per la realizzazione di servizi su Web. In un Web Service SOAP, che propone una visione del Web incentrata sul concetto di servizio, il protocollo http è utilizzato a livello di trasporto, e su di esso è definito un servizio applicativo basato su:

  • la specifica delle interfacce (operazioni), contenuta nel WSDL (documento XML in grado di descrivere le funzioni e i parametri di un Web Service SOAP);
  • la definizione dei datatype, contenuta in un corrispondente documento XSD.

L’approccio adottato dai Web Service basati su SOAP è, in sintesi, una sorta di adattamento dalle tecnologie di interoperabilità ed elaborazione distribuita, già esistenti al di fuori del Web, su http ma senza sfruttarne appieno le potenzialità.
L’esistenza di documenti WSDL ed XSD per definire un Web Service SOAP, inoltre, favorisce l’uso di tool per creare automaticamente client applicativi nei diversi linguaggi di programmazione ma allo stesso tempo induce a creare una forte dipendenza tra client e server.
Negli anni 2000 l’uso delle API è stato l’elemento vincente per l’ascesa del cosiddetto “programmable web”, il modello di erogazione dei servizi adottato dagli OTT; questa evoluzione è stata accompagnata da un ulteriore sviluppo tecnologico nelle API, con l’adozione di protocolli per l’elaborazione distribuita sempre più “leggeri” (da SOAP/Web Services a REST) per adattarsi al meglio alle caratteristiche di Internet ed alle esigenze dei programmatori che sviluppano applicazioni di tipo Web.
In REST l’approccio all’API design cambia radicalmente:

  • non si ragiona più in termini di servizi ma in termini di risorse;
  • si sfrutta http per quello che è: un protocollo a livello applicativo e non di trasporto, di cui si applicano le azioni previste dai suoi metodi: get, put, post e delete.

REST, in questo modo, tende a conservare e ad esaltare le caratteristiche intrinseche del Web evidenziandone la predisposizione ad essere una piattaforma per l’elaborazione distribuita, senza aggiungere nulla a quanto è già esistente sul Web per consentire ad applicazioni remote di interagire.
Il primo a proporre l’approccio REST (REpresentational State Transfer, ovvero trasferimento dello stato di rappresentazione) è stato Roy Fielding, nel 2000, nella sua tesi di dottorato "Architectural Styles and the Design of Network-based Software Architectures".
I principi dell’approccio REST sono i seguenti:

  • le risorse hanno un proprio identificativo univoco ed indirizzabile che non è altro che un indirizzo URI (Uniform Resource Identifier), a tutti gli effetti equivalente agli indirizzi Web che usualmente inseriamo nei nostri browser per accedere ad una pagina specifica o ad un documento presente in rete;
  • le interazioni tra client e server devono essere stateless, cioè devono contenere tutte le informazioni necessarie per gestire la richiesta (parametri, contesto e dati), senza richiedere una memorizzare sul server;
  • sono supportate, nell’interazione tra client e server, le cosiddette operazioni CRUD (Create, Read, Update, Delete), mappate sui metodi dell’HTTP:
    -           (Create) POST, per creare una risorsa sul server;
    -           (Read) GET, per recuperare in sola lettura lo stato di una risorsa.;
    -           (Update) PUT, per aggiornare lo stato della risorsa;
    -           (Delete) DELETE, per cancellare una risorsa;
  • è raccomandato l’utilizzo della cache, a diversi livelli, per l’ottimizzazione delle performance;
  • l’interazione tra client e server è semplificata, disaccoppiando i sistemi e consentendo che le due componenti possano evolvere in modo indipendente.

Per quel che riguarda le strutture dati, REST può prevedere sia l’utilizzo dell’XML oppure una struttura semplificata denominata JSON.
L’agilità dello stile REST, la possibilità di suo utilizzo da una molteplicità di dispositivi dotati di un client http senza la necessità di ulteriori strumenti, la semplicità di sviluppo lo hanno reso il naturale “linguaggio” di interazione tra sistemi sul Web, contribuendo alla crescita delle API sul Web.
Nel confronto tra REST e Web Services API è comunque opportuno evidenziare che in contesti enterprise di medio-grandi dimensioni, in cui siano preponderanti gli aspetti di formalità (governance, supporto, definizione di un contratto) tra gli elementi delle architetture, o laddove vi sia la necessità di supportare interazioni di tipo asincrono e su altre modalità di trasporto oltre l’http (e.g. queuing) i Web Service risultano ancora l’approccio più utilizzato per il “consumo interno” di servizi.

 

Figura A - Modello Remote Procedure Call

 

Torna all'articolo