Quello dei web services è argomento piuttosto complesso da affrontare in poche righe, che sia un articolo o una pagina di libro. Proviamo a capire cosa sono le API e le tecnologie come REST utili alla loro realizzazione.
Indice dei contenuti
Web Services
Sui banchi di scuola siamo abituati a studiare applicazioni relativamente semplici che girano spesso unicamente sul nostro pc da lavoro. Interfaccia grafica, dati e intelligenza, tutta racchiusa in un solo eseguibile, perlopiù in PHP. Del resto siamo analogamente abituati a percepire come software solo quello che ha una interfaccia con cui un utente può interagire, cliccare, inserire dati ecc. I web services stravolgono questo concetto. Un web service non è detto risieda su un solo server, che sfrutti un solo script o che contenga tutte le componenti gui o backend, ma probabilmente ha componenti differenti dislocate su diversi server e non è neanche scontato che abbia un’interfaccia grafica attraverso la classica pagina HTML. Non è neanche detto che sia realizzato con un solo linguaggio di programmazione o una solo tecnologia: un web service per sua natura può dialogare con più elementi, script, software, web server per trovare una sintesi finale. Secondo il W3C è un sistema software progettato per supportare l’interoperabilità tra diversi elaboratori su una stessa rete oppure in un contesto distribuito. Alla base però di tutto questo trambusto c’è una cosa essenziale: far scambiare dati tra i vari attori.
Le radici del web service: le API
Un’API può essere paragonata al funzionamento di un ristorante con un menu. Il cliente (client) sceglie un piatto dal menu (API), che rappresenta un insieme predefinito di opzioni. La richiesta viene inviata alla cucina (server), che prepara il piatto e lo consegna al cliente (in un formato che può essere sia una pagina html ma anche altro formato dati). Il cliente non ha bisogno di sapere come la cucina lavora o organizza le sue operazioni, ma deve solo ricevere il piatto richiesto secondo le aspettative. La standardizzazione dei menu permette a clienti e cucine di interagire senza equivoci, semplificando il processo (ad esempio non posso chiedere fuori menù o aggiunte e personalizzazioni al piatto).
Senza le API, non esisterebbe un linguaggio comune per lo scambio di informazioni tra applicazioni o servizi software. I programmatori di sistemi diversi dovrebbero coordinarsi ogni volta per stabilire come condividere i dati, rendendo il processo lungo e inefficiente, lasciando ai programmatori software l’arduo compito di sincronizzarsi sul da fare.
Sono disponibili diverse architetture API, ma tutte sono base fondate della realizzazione di Web Services. Le API in generale possono essere definite anche come Web API, posi specializzate con determinate tecnologie.
La tecnologia REST
Acronimo di REpresentational State Transfer, prevede alla base di un web service, una porzione di programma capace di interpretare gli URL, le classiche richieste che facciamo con la barra di ricerca del browser ma che possono essere anche immerse nel codice PHP/JS. Tali URL specifici quindi giungono al server in più modi. Cambia il modo di concepire gli URL stessi e le risorse/script per come li conosciamo nel PHP standard, dove già conosciamo GET e POST (e PUT e DELTE) e il passaggio di parametri:
| http://www.pippo.it/articolo.php?id=1234 | Qui un URL standard dove chiedo una risorsa, una pagina php/html e gli passo un parametro col GET |
| http://www.pippo.it/articolo/id/1234 | Questa è una richiesta stile REST dove non chiedo una pagina ma un’azione che può avere come risposta una pagina o altro |
Con questo approccio REST, è scontato andare a realizzare della API REST, dette API RESTful, dove l’attenzione non è più sulla risorsa secca ma sull’azione. Ecco perché rappresenta un ottimo modo per esprimere le CRUD, Create, Read, Update e Delete, le classiche chiamate che vengono fatte ad un database per gestire i dati. Il REST diventa un ottimo sistema per scambiare dati nei formati JSON e XML proprio per la sua natura di URL non vincolato alle sole pagine html o php. La realizzazione di API sui banchi di scuola non è ostica e troverete in queste pagine degli esempi.
WebSocket
Le tecnologie REST viste poco sopra, sono pensate per essere unidirezionali e senza un assiduo e ripetuto scambio di dati: o mando o ricevo con la API prescelta e solo su richiesta, ogni tanto. Il WebSocket supera questa rigidità ispirandosi alla tecnologia dei socket TCP (che si studiano spesso in quarto ITT informatica). WebSocket è un protocollo di comunicazione che consente una connessione bidirezionale e persistente tra un client (ad esempio, un browser) e un server. A differenza del tradizionale modello di richiesta e risposta di HTTP, i WebSocket permettono lo scambio continuo di dati in tempo reale senza dover instaurare una nuova connessione per ogni messaggio. Questo li rende particolarmente adatti per applicazioni che richiedono aggiornamenti rapidi e costanti, come chat, giochi online, monitoraggio finanziario in borsa o criptovalute, o applicazioni IoT e domotica. E’ una tecnologia con ampi spazi per essere insegnata anche sui banchi di scuola soprattutto se l’argomento dei socket non viene affrontato con i tradizionali strumenti Java/C#/Python.
SOAP
REST e SOAP sono due tecniche differenti per la trasmissione dati sul web, l’ambiente distribuito per eccellenza. Entrambi definiscono come costruire delle API, application programming interfaces (APIs), che permettono ai dati di essere scambiati tra diverse applicazioni web.
Acronimo di Simple Object Access Protocol, è una tecnologia per applicazioni enterprise. Non è una vera implementazione software ma un protocollo che istruisce sul come realizzare gli applicativi. In soldoni, la struttura risulta complessa ma allo stesso tempo robusta e sicura, fortemente incentrata sullo scambio di dati ed informazioni tra le componenti dell’applicativo con l’uso di XML con specifica sintassi orientata a SOAP. Al di la delle definizione da conoscere, la sua implementazione potrebbe essere complessa sui banchi di scuola.
SOAP vs. REST
Molti sistemi di vecchio stampo aziendali continuano ad usare SOAP mentre REST sta entrando tra le preferenze di progettisti e programmatori per la rapidità di sviluppo negli scenari web. REST è, del resto, un set di linee guida che poi possono essere gestite e sviluppate in molte salse, con flessibilità e adattabilità ai singoli contesti piuttosto che le procedure con scambi di file XML di SOAP. REST è, per tanto, leggero, pronto per le esigenze anche di domotica e IoT dove i dispositivi sono piccoli e con scarsa capacità di calcolo. SOAP di contro è robusto e sicuro di default, caratteristica desiderata dagli scopi professionali/aziendali. Certo è più complesso da sviluppare e gestire. Molte tecnologie e web service rilasciano API REST, a cominciare da Spaggiari e Google Maps con tanti servizi collegati, Amazon. REST è ormai diventato predominante rispetto a SOAP e le altre tecnologie proprio per la sua comodità non solo verso l’utente finale ma anche per interconnettere servizi non diretti ad utenti umani ma tra server che collaborano tra loro nel backend e si scambiano informazioni e dati magari sotto forma di JSON.
Altre tecnologie
Un po’ in disuso magari rispetto alle precedenti tecnologie, ma meritano la menzione.
RPC: Remote Procedure Call) si riferisce all’attivazione da parte di un programma o di una procedura attivata su un computer o dispositivo diverso da quello sul quale il programma viene eseguito. E’ un modo molto trasparente di eseguire una funzionalità da remoto come se fosse invocata localmente (pensiamo alle chiamate di sistema fork già studiate ad esempio qui). Si sta diffondendo una sua versione gRPC che sfrutta meccanismi simili alle API Rest.
CORBA: è una versione del mondo RPC con uno strato detto middleware che integra le chiamate remote tra linguaggi diversi.
XML-RPC: è il precursore di SOAP
Microservizi
Abbiamo capito come la modularità di codice, responsabilità di un software sia il trend per realizzare applicativi complessi. Un microservizio è un’unità autonoma di un’applicazione più ampia, progettata per essere indipendente e focalizzata su una specifica funzionalità o dominio (ad esempio, gestione degli ordini, elaborazione dei pagamenti, ecc.). I microservizi rappresentano un’architettura in cui l’applicazione è suddivisa in più servizi modulari, che comunicano tra loro tramite protocolli standard, spesso utilizzando API (incluso REST).
In un’applicazione e-commerce, il microservizio “Catalogo” gestisce i prodotti, mentre il microservizio “Carrello” gestisce gli ordini.
Le API RESTful sono spesso utilizzate come interfaccia di comunicazione tra i microservizi stessi o tra microservizi e client esterni. Tuttavia, i microservizi non sono obbligati a usare REST: possono comunicare con altri protocolli in base alle necessità.
Un esempio di integrazione:
- Il microservizio “Catalogo” offre un’API RESTful per accedere ai dati dei prodotti.
- Il microservizio “Carrello” utilizza questa API per mostrare i prodotti selezionati dall’utente.
Ultima modifica 17 Novembre 2024
