API e WEB Services

In questo articolo, API e WEB Services impariamo a conoscere cosa sono le Application Programming Interfaces e i WEB Service. Dopo aver imparato i concetti fondamentali possiamo fare riferimento alla guida PHP all’interno della quale troviamo una sezione per implementare un WEB Service in PHP e come testarlo

Indice dei contenuti

Introduzione

Il Web è emerso come una delle più grandi piattaforme per la condivisione di documenti in formato ipertestuale, interconnessi mediante parole chiave. Questa condivisione avviene indipendentemente dalla piattaforma hardware o software utilizzata. Col tempo, il Web ha subito una continua evoluzione, grazie anche alla standardizzazione di concetti fondamentali come:

• URI (Uniform Resource Identifier): Un meccanismo per individuare risorse in rete.
• HTTP (Hypertext Transfer Protocol): Un protocollo semplice e leggero per la comunicazione tra client e server.
• HTML (HyperText Markup Language): Un linguaggio per la rappresentazione e formattazione dei contenuti.

Nel 1994, la necessità di definire regole comuni ha portato alla creazione del World Wide Web Consortium (W3C). Questo organismo ha rivestito un ruolo cruciale nello sviluppo del Web, proponendo standard noti come W3C Recommendations, basati sulle necessità delle organizzazioni e delle aziende.

Il Web come piattaforma applicativa distribuita

Dalla semplice condivisione di documenti, il Web si è trasformato in una vera e propria piattaforma applicativa. Ai documenti testuali si sono aggiunti contenuti multimediali e l’interazione tra componenti software è diventata un elemento chiave. L’introduzione di applicazioni interoperabili lato server, come CGI, JSP, PHP e ASP, ha segnato una svolta verso la dinamicità, permettendo alle pagine HTML di evolversi da statiche a dinamiche.

Le sfide dell’integrazione

Nonostante i progressi, l’evoluzione del Web ha introdotto problemi significativi, tra cui:

1. Integrazione tra applicazioni sviluppate indipendentemente: Le applicazioni create in diverse parti del mondo spesso non erano progettate per comunicare tra loro.
2. Integrazione all’interno di una singola azienda: La coesistenza di tecnologie eterogenee ha reso complessa la connessione tra sistemi interni.

Il successo del Web ha inoltre portato alla necessità di interazioni più sofisticate tra applicazioni in contesti sempre più vari.

Architetture distribuite e l’avvento dei Web Services

Con la diffusione delle architetture distribuite negli anni ’90, era necessario stabilire regole di interoperabilità. Sono nate quindi soluzioni come:

• CORBA (1992): Standard multipiattaforma per linguaggi orientati agli oggetti.
• Java RMI (1996): Specifico per l’ecosistema Java.
• DCOM (1996): Tecnologia proprietaria di Microsoft.

Tuttavia, questi approcci soffrivano di limitazioni legate ai protocolli di comunicazione e alle tecnologie coinvolte. Per superare tali ostacoli, si sono proposte soluzioni basate su RPC (Remote Procedure Call) e XML, che garantivano l’interoperabilità tra piattaforme software/hardware diverse.

Web Services: Una nuova frontiera

L’introduzione dei Web Services ha rappresentato un passo avanti nella standardizzazione delle tecnologie, consentendo l’interazione trasparente tra applicazioni sviluppate in linguaggi di programmazione differenti e operanti su sistemi eterogenei. In sintesi, un Web Service è un sistema software progettato per supportare l’interazione tra applicazioni, sfruttando le tecnologie e gli standard del Web.

Capitolo 1: Le API – Il Cuore dell’Interoperabilità

Cosa sono le API?

Le API, acronimo di Application Programming Interface, rappresentano un insieme di regole e protocolli che consentono a diverse applicazioni software di comunicare tra loro. Immaginiamole come un ponte che collega programmi e sistemi, rendendo possibile lo scambio di informazioni e funzionalità in modo standardizzato.

Un’API non è un software completo, ma una porta d’accesso che permette agli sviluppatori di utilizzare funzionalità preesistenti senza doverle programmare da zero. In sostanza, le API facilitano l’integrazione e l’interoperabilità tra componenti software che, altrimenti, non sarebbero in grado di comunicare.

Struttura di un’API

Tipicamente, un’API è composta da:

• Endpoint: Rappresentano i punti di contatto attraverso cui il client invia richieste al server.
• Metodi: Ogni API supporta diversi metodi, come GET, POST, PUT e DELETE, che determinano le azioni da eseguire.
• Formati di scambio dati: I dati vengono scambiati utilizzando formati standardizzati come JSON (JavaScript Object Notation) o XML (eXtensible Markup Language).

Tipologie di API

Le API possono essere classificate in diverse categorie in base al loro utilizzo e alla loro accessibilità:

1. API Pubbliche (o Aperte): Accessibili a chiunque, spesso utilizzate per promuovere l’integrazione di terze parti e favorire l’innovazione.
2. API Private: Restrizioni sull’accesso per garantire la sicurezza e l’integrità delle applicazioni interne a un’organizzazione.
3. API Partner: Progettate per essere condivise tra aziende o organizzazioni con rapporti di collaborazione.
4. API Composite: Combina più API per creare flussi di lavoro complessi e aumentare l’efficienza.
5. API WEB: Utilizzano HTTP per la comunicazione nel WEB e sono basate su diversi standard (REST, SOAP,..)
6. API di libreria: forniscono un insieme di funzioni e procedure per l’utilizzo di codice
7. API di Sistema Operativo: consentono alle applicazioni di accedere alle funzionalità del sistema operativo

Come funzionano?

Il processo di utilizzo di un’API segue un modello client-server. Il client invia una richiesta al server attraverso l’endpoint dell’API e riceve una risposta strutturata. Questo meccanismo permette di accedere a servizi e dati senza la necessità di conoscere i dettagli interni del software del server.

Un esempio pratico? Le API di Google Maps consentono a siti web e app di incorporare mappe interattive e di sfruttare funzionalità di navigazione senza dover sviluppare una piattaforma cartografica da zero.

L’importanza delle API nel Web moderno

Nel contesto delle architetture distribuite, le API giocano un ruolo cruciale. Consentono agli sviluppatori di creare applicazioni modulari, migliorando la scalabilità, la manutenibilità e la velocità di sviluppo. Grazie alle API, il Web non è solo un insieme di pagine, ma una rete dinamica di servizi che collaborano per offrire esperienze sempre più personalizzate e coinvolgenti.

Capitolo 2: I Web Service – Fondamenti e Implicazioni

La definizione di W3C

Il World Wide Web Consortium (W3C), fondato nel 1994 da Tim Berners-Lee, è l’organizzazione principale responsabile della standardizzazione del Web. Il suo obiettivo primario è quello di garantire uno sviluppo coerente e interoperabile delle tecnologie Web. Attraverso la definizione di raccomandazioni tecniche, il W3C assicura che le innovazioni siano accessibili e compatibili su scala globale.

Cosa sono i Web Service e a cosa servono?

Un Web Service è una tecnologia che consente a diverse applicazioni software di comunicare tra loro attraverso Internet. Basati su protocolli standard come HTTP e SOAP, i Web Service permettono l’integrazione tra sistemi e linguaggi di programmazione eterogenei. Il loro scopo principale è quello di facilitare l’interoperabilità, offrendo la possibilità di condividere dati e funzionalità tra applicazioni distribuite.

In concreto, i Web Service fungono da “mediatori” che trasmettono richieste e risposte tra componenti software, indipendentemente dalla piattaforma o dal linguaggio utilizzato.

L’integrazione tra API e Web Services

Le API e i Web Services sono strettamente correlati ma distinti. Mentre un’API definisce un set di regole per la comunicazione tra applicazioni, i Web Services implementano queste regole utilizzando i protocolli e le tecnologie Web. In altre parole, un Web Service può essere considerato un tipo di API progettata per funzionare su Internet.

Questo rapporto consente agli sviluppatori di sfruttare il potenziale di entrambi. Le API forniscono il “linguaggio comune” necessario, mentre i Web Services estendono questa capacità al livello delle comunicazioni globali attraverso il Web.

Il “Web” nei Web Services: una piattaforma M2M

Nonostante il termine “Web”, i Web Services non sono rivolti agli utenti finali tramite un’interfaccia utente, come accade con i siti Web. Piuttosto, rappresentano un sistema Machine-to-Machine (M2M). Questo significa che comunicano direttamente con altre applicazioni attraverso protocolli Web standard, come HTTP e XML.

Il loro utilizzo è fondamentale per molte applicazioni moderne, dalle integrazioni aziendali alle piattaforme di e-commerce, fino alle tecnologie IoT (Internet of Things).

Dalle RPC ai Web Services: un’evoluzione

L’origine dei Web Services risale al concetto di Remote Procedure Call (RPC), introdotto per consentire a un programma di eseguire procedure su un server remoto. Con l’uso di formati come XML, le RPC hanno permesso la comunicazione tra sistemi differenti. Tuttavia, le limitazioni delle RPC, legate alla mancanza di standardizzazione universale, hanno aperto la strada ai Web Services.

I Web Services hanno superato queste barriere implementando protocolli come SOAP e REST, che garantiscono una maggiore flessibilità e interoperabilità. SOAP, ad esempio, utilizza XML per il formato dei messaggi, mentre REST sfrutta i metodi HTTP per la comunicazione, risultando più leggero e adatto alle esigenze moderne.

Capitolo 3: Modelli per Web Service – SOAP e REST

SOAP: Un approccio evolutivo alla comunicazione tra sistemi

Nel definire i Web Service, si è scelto un approccio evolutivo, basato sull’uso di HTTP come protocollo di trasporto delle informazioni. Questa decisione ha permesso di sfruttare l’infrastruttura già esistente di Internet, riducendo i costi e semplificando l’adozione. Per descrivere i dati scambiati tra client e server, si è introdotto XML (eXtensible Markup Language), uno standard efficace per rappresentare richieste e risposte in un formato leggibile e universale.

Questo approccio si inserisce in una più ampia architettura orientata ai servizi, nota come Service Oriented Architecture (SOA). L’obiettivo primario di SOA è:

• Ottimizzare i costi: Riducendo gli investimenti nello sviluppo da zero.
• Massimizzare l’uso delle tecnologie esistenti: Integrando soluzioni già disponibili.
• Adattarsi alle evoluzioni tecnologiche: Rispondendo alle mutevoli esigenze del mercato globale.

Caratteristiche chiave di SOA

SOA offre una piattaforma per costruire servizi applicativi con caratteristiche fondamentali:

• Accoppiamento lasco (Loosely Coupled): Gli utenti non si devono occupare di scegliere quali servizi utilizzare; è l’infrastruttura a gestire la comunicazione.
• Trasparenza di localizzazione (Location Transparent): I dettagli tecnici vengono nascosti al cliente, semplificando l’interazione.
• Indipendenza dal protocollo (Protocol Independent): Le implementazioni possono essere aggiornate senza modificare le interfacce, garantendo flessibilità.

Attori nell’architettura SOA

Tre entità collaborano in SOA per garantire il funzionamento dei servizi:

1. Service Consumer (o Requestor): Un’entità software che richiede un servizio interrogando un Service Registry.
2. Service Registry: Contiene il repository dei servizi disponibili e fornisce al consumer i dettagli necessari (contratti e endpoint del provider).
3. Service Provider: L’entità che implementa il servizio richiesto, risponde alle richieste del client e pubblica il contratto che descrive l’interfaccia del servizio.

Le fasi del ciclo di vita di un Web Service SOAP

Il ciclo di vita di un Web Service basato su SOAP si articola in diverse fasi:

1. Creazione e pubblicazione del servizio: Il Service Provider descrive il servizio attraverso un documento WSDL (Web Service Description Language), un formato XML che include dettagli come nome dei metodi, parametri e valori di ritorno. Questo documento viene pubblicato su un registro conforme allo standard UDDI (Universal Description, Discovery and Integration).
2. Discovery del servizio: Il Service Consumer interroga il registro UDDI per identificare i servizi necessari. Se il servizio è già noto, questa fase può essere saltata.
3. Acquisizione delle specifiche: Una volta individuato il servizio, il consumer ottiene il documento WSDL per scoprire l’indirizzo (URI) e le modalità di utilizzo.
4. Interazione client-server: Il client crea uno strato software chiamato stub, che si occupa della comunicazione con lo strato software lato server, noto come skeleton. Questi componenti gestiscono la conversione dei messaggi SOAP in formato XML.

Comunicazione SOAP: Un processo dettagliato

La comunicazione tra client e server segue un processo ben definito:

1. Richiesta del client: Lo stub lato client invia una richiesta al servizio, convertendo i dati in un messaggio XML conforme al protocollo SOAP.
2. Elaborazione lato server: Lo skeleton lato server riceve il messaggio SOAP, lo traduce in istruzioni eseguibili e processa la richiesta.
3. Risposta del server: Il risultato dell’elaborazione viene confezionato in un messaggio SOAP e inviato al client.
4. Ricezione del client: Lo stub lato client elabora la risposta e la restituisce all’applicazione richiedente.

Un messaggio SOAP è strutturato in:

• Envelope: La busta che racchiude il messaggio.
• Header: Contiene metadati come credenziali di autenticazione e ID della transazione.
• Body: Include i dati veri e propri, come documenti o parametri delle chiamate.

La pila protocollare SOAP

La pila protocollare per Web Service SOAP si compone di:

• UDDI (Universal Description, Discovery and Integration): Registro per la scoperta dei servizi.
• WSDL (Web Service Description Language): Descrive l’interfaccia esterna del servizio per consentire agli sviluppatori di crearne un client.
• SOAP (Simple Object Access Protocol): Protocollo per lo scambio di messaggi, basato su XML.
• XML (eXtensible Markup Language): Standard per lo scambio di dati e la struttura dei messaggi.

REST: Un approccio leggero e flessibile per i Web Service

REST (Representational State Transfer) rappresenta un’alternativa leggera e moderna a SOAP per la creazione di Web Service. Diversamente da SOAP, che si basa su chiamate remote e richiede una complessa infrastruttura di messaggi XML, stub/skeleton e contenitori applicativi, REST è progettato per essere semplice ed efficiente. Le sue caratteristiche principali includono:

• Identificazione delle risorse tramite URI (Uniform Resource Identifier): Ogni risorsa viene individuata tramite i classici link Web. Si chiamano ENDPOINT
• Metodi HTTP: Le operazioni sulle risorse vengono eseguite utilizzando comandi HTTP standard come GET, PUT, POST e DELETE.

Differenze tra REST e SOAP

REST utilizza un approccio diretto, riducendo la complessità rispetto a SOAP. Ad esempio:

• In REST, per leggere un catalogo di prodotti, basta utilizzare il metodo HTTP GET sull’URI che rappresenta il catalogo. Un esempio sarebbe accedere a http://www.nomenegozio.it/catalogo/prodotti. Il server corrisponde questa URI a una query sul database e restituisce i dati richiesti in formati come TXT, HTML, XML o JSON.
• SOAP, invece, richiede un’architettura più elaborata basata su messaggi XML strutturati e l’implementazione di stub e skeleton per gestire le richieste e risposte.

REST si adatta perfettamente all’ecosistema Web, sfruttando al meglio le infrastrutture già esistenti per rendere possibile l’interazione tra applicazioni distribuite. La sua semplicità consente a sistemi indipendenti di comunicare senza necessità di definire complessi standard di interazione.

Caratteristiche dell’architettura REST

L’approccio REST, formalizzato per la prima volta nel 2000 da Roy Fielding nella sua tesi di dottorato, si basa su cinque principi fondamentali:

1. Identificazione delle risorse tramite URI: Ogni elemento viene rappresentato e individuato univocamente attraverso un URI chiaro e strutturato.
2. Uso esplicito dei metodi HTTP: Le operazioni CRUD (Create, Read, Update, Delete) vengono mappate direttamente su comandi HTTP.
3. Risorse autodescrittive: I dati scambiati descrivono se stessi, consentendo al client di comprendere autonomamente la loro natura.
4. Interazioni stateless: Ogni richiesta del client al server è indipendente, senza necessità di memorizzare lo stato tra le comunicazioni.
5. Supporto a diversi formati di comunicazione: REST utilizza XML, JSON o entrambi, rendendolo versatile e facilmente integrabile.

Esempi di URI REST

Gli URI “parlanti” usati in REST aiutano a identificare chiaramente risorse e operazioni, come mostrato di seguito:

• http://www.miaApplicazione.com/clienti/1111 – Un determinato cliente.
• http://www.miaApplicazione.com/prodotti/2222 – Un prodotto specifico.
• http://www.miaApplicazione.com/prodotti?colore=verde – Un insieme di prodotti filtrati (ad esempio per colore).
• http://www.miaApplicazione.com/ordini/2021/334455 – Un ordine effettuato nel 2021.

REST promuove un’interazione diretta e snella: ad esempio, per ottenere i dettagli di una risorsa è sufficiente un’operazione GET sull’URI della risorsa stessa.

I vantaggi di REST rispetto a SOAP

Il successo di REST è dovuto alla sua leggerezza e facilità di utilizzo:

1. Focalizzato sulle risorse: REST organizza le operazioni attorno alle risorse, mentre SOAP è orientato ai servizi.
2. Integrazione semplificata: REST utilizza le chiamate HTTP standard per accedere alle risorse, rendendolo più accessibile rispetto alla configurazione dettagliata di SOAP.
3. Flessibilità e scalabilità: REST consente un’implementazione rapida e semplice, particolarmente adatta per applicazioni distribuite e accessibili da dispositivi mobili.

Negli ultimi anni, REST è emerso come modello dominante per la progettazione di Web Service, con la maggior parte dei provider di API che adottano questo approccio.

Le operazioni CRUD e i metodi HTTP

REST sfrutta i metodi HTTP per definire le operazioni CRUD:

• POST (Create): Crea una nuova risorsa.
• GET (Read): Recupera una risorsa esistente.
• PUT (Update): Aggiorna o modifica lo stato di una risorsa.
• DELETE (Delete): Rimuove una risorsa.

Esempio: per accedere a un’istanza di una risorsa, un client esegue una richiesta GET sull’URI corrispondente. Tuttavia, REST richiede che il metodo HTTP sia utilizzato per la sua funzione corretta. Ad esempio, creare una risorsa tramite GET non è conforme ai principi REST, poiché GET dovrebbe essere impiegato esclusivamente per leggere dati.

RESTful API

Le API che seguono i principi REST sono definite RESTful API. Questi Web Service devono rispettare una serie di vincoli fondamentali:

• Interazione client-server.
• Comunicazioni stateless.
• Utilizzo di meccanismi di caching.
• Interfaccia uniforme per le risorse.
• Possibilità di costruire ulteriori layer applicativi partendo dal servizio di base.

Conclusioni

Dopo aver esplorato le potenzialità delle API e dei WEB Services possiamo procedere alla realizzazione di semplici WEB Services attraverso, ad esempio, il pacchetto json-server di Node.js o creando un WEB Service REST in PHP. Fare riferimento alle seguenti guide:

• Guida alla realizzazione di WEB Service con json-server
• Guida alla realizzazione di un WEB Service REST in PHP