• introduzione-API-REST

    Introduzione alle API REST

    In questo post verranno mostrati i concetti introduttivi alle API REST.

    I concetti di base delle API REST

    Prendi un attimo in considerazione alcune attività, che possibilmente esegui tutti i giorni, o quasi:

    • leggere su un dispositivo mobile la versione digitale del tuo quotidiano preferito;
    • consultare un sito di e-commerce come Amazon;
    • interagire con un social media come Facebook o Twitter;
    • effettuare delle operazioni dal tuo home banking;
    • guardare un programma in streaming;
    • cercare offerte di viaggio.

    Cosa hanno in comune tutte queste attività? Probabilmente tutte stanno utilizzando delle informazioni da Internet mediante delle API REST (Application Programming Interface REpresentational State Transfer).

    Un esempio molto semplice per capire cosa siano le API TEST e come funzionano è la biblioteca, in cui ci sono dei bibliotecari, delle risorse (libri, CD audio, DVD) che gli utenti desiderano prendere in prestito.

    API-REST-library

    Da un lato abbiamo un servizio (ad esempio un server con un database), che contiene delle risorse. Dall’altro abbiamo degli utenti (un’applicazione Web, un’app per dispositivi mobili, o qualsiasi altro client che utilizzi l’accesso ai dati), che sono gli utilizzatori finali del servizio, che effettuano delle richieste. In mezzo c’è  il bibliotecario (l’API REST), che riceve delle richieste dai client, le elabora e gestisce le risposte.

    Il funzionamento è il seguente:

    • l’API REST è in attesa di richieste;
    • un client invia una richiesta all’API REST, ad esempio vuole ottenere una risorsa;
    • l’API REST riceve la richiesta, identifica la risorsa richiesta, individua il formato dei dati corrispondenti al formato della richiesta, raggruppa tutto inserendo un’intestazione contenente alcune informazioni, e la manda come risposta al client;
    • il client riceve la risposta e la elabora per gli usi che gli servono.
    • l’API REST attende l’arrivo di altre richieste;

    In questo esempio, abbiamo un client che invia richieste all’API REST. Nella maggior parte delle applicazioni ci saranno diverse centinaia, o migliaia, o milioni di client che fanno richieste, quindi il bibliotecario sarà molto impegnato. Ma il flusso reale è esattamente lo stesso. Il client effettua la richiesta (request), l’API REST riceve la richiesta, raccoglie e analizza i dati e restituisce i dati e l’intestazione della risposta (response) al client. 

     

    Cosa sono esattamente le REST API

    REST e API sono acronimi per REpresentational State Transfer (REST) e Application Programming Interface (API). Per capire cosa sono, consultiamo la pagina MDN (Mozilla Developer Network) relativa alla voce REST: all’indirizzo https://developer.mozilla.org/en-US/docs/glossary/REST troverai la seguente definizione:

    REpresentational State Transfer (REST) refers to a group of software architecture design constraints that bring about efficient, reliable, and scalable distributed systems. A system is called RESTful when it adheres to those constraints.

    Traduciamo:

    REpresentational State Transfer (REST) si riferisce ad un gruppo di vincoli di progettazione dell’architettura software che consentono di creare sistemi distribuiti efficienti, affidabili e scalabili. Un sistema si chiama RESTful quando aderisce a tali vincoli.

    Quindi REST non è una tecnologia specifica, ma piuttosto un’architettura di dati e una metodologia di progettazione che produce output e comportamenti prevedibili e coerenti ricevendo una serie di metodi standard denominati verbi (GET, POST, PUT, DELETE, etc …) e restituendo dati strutturati standardizzati, in genere JSON o XML, denominati risorse.

    Un’API è un insieme di funzionalità e regole esistenti all’interno di un software che consente l’interazione tra il software ed altri elementi, come altri software. Nel contesto delle API REST, l’API è la raccolta di strumenti utilizzati per accedere e lavorare con le risorse REST. Puoi pensare al concetto di REST come ad un bibliotecario e all’API come il linguaggio usato per parlarci.

    I vincoli delle REST API

    Dalla definizione di MDN, abbiamo visto che “REpresentational State Transfer (REST) si riferisce ad un gruppo di vincoli di progettazione dell’architettura software che consentono di creare sistemi distribuiti efficienti, affidabili e scalabili. Un sistema si chiama RESTful quando aderisce a tali vincoli.”

    Quanti e quali sono questi vincoli? Sono in tutto sei e sono i seguenti:

    1. Architettura Client-Server
    2. Statelessness
    3. Cacheability
    4. Layered system
    5. Code on demand
    6. Uniform interface

    Architettura Client-Server

    Questo vincolo garantisce una corretta separazione dei compiti. Il client gestisce i problemi dell’interfaccia utente mentre il server gestisce i problemi di archiviazione dei dati. In questo modo abbiamo un sistema altamente portatile in cui un servizio può gestire molti client e interfacce diverse senza sapere o preoccuparsi di come sono fatte tali interfacce o che cosa stanno facendo. In breve, abbiamo una separazione completa tra il contenuto e la sua presentazione.

    rest-client-server

    Statelessness

    Vincolo “essere senza stato”. Non può essere memorizzato sul server tra le richieste nessun contesto o informazione del cliente, cioè nessuno stato. Il cliente è responsabile di tenere traccia del proprio stato e tutte le richieste inviate da un client devono essere autosufficienti e complete. Se lo stato del client è rilevante, deve essere inviato insieme a una richiesta. Ad esempio, al server può essere chiesto di passare un token di autenticazione per un determinato periodo di tempo per consentire l’esecuzione di richieste mediante autenticazione.

    rest-stateless

    Cacheability

    Il caching è parte integrante dell’architettura web e dell’ottimizzazione delle prestazioni. Tutte le risposte REST devono poter essere chiaramente contrassegnate come memorizzabili nella cache (cacheable) o non memorizzabili nella cache (non-cacheable) per garantire che la memorizzazione nella cache funzioni come previsto sul client. Ovviamente conviene memorizzare nella cache risposte che non cambieranno o che cambieranno raramente, mentre conviene bloccare il caching per le risposte in continua evoluzione.

    rest-cacheability

    Layered system

    Layered system, sistema a strati. Il sistema deve essere progettato in modo che il client non possa sapere e non si cura se è collegato direttamente al server o ad un intermediario come un mirror o un CDN. Questo garantisce la scalabilità e serve anche per la sicurezza.

    Code on demand

    I server sono autorizzati a trasferire codice eseguibile sotto forma di JavaScript lato client e componenti compilati al client per estendere e personalizzare le funzionalità. Questo è un uso meno comune di REST, ma deve essere supportato affinché un servizio sia REST.

    rest-run-code

    Uniform interface

    Questo vincolo si compone di quattro sotto-vincoli:

    1. Identificazione della risorsa nella Request. Nei sistemi REST sul Web, un URI viene utilizzato per inviare una richiesta e quell’URI specificherà la risorsa che sta cercando. Quindi, un’URI authors/cantali/bio sta richiedendo la mia biografia come risorsa. L’URI della request deve specificare quale risorsa sta cercando e quale formato deve usare la response. I dati delle risorse possono essere archiviati come una tabella in un database relazionale, e la rappresentazione restituita può essere JSON o XML o anche HTML.
    2. Manipolazione della risorsa tramite le rappresentazioni. Un’interfaccia uniforme deve consentire la manipolazione delle risorse attraverso le rappresentazioni. Ciò significa che una volta che un client ha una rappresentazione di una risorsa, può anche modificare o eliminare quella risorsa. In altre parole, il client con il giusto livello di accesso può controllare ciò che è memorizzato sul server.
    3. Messaggi auto-descrittivi. Un’interfaccia uniforme deve creare messaggi auto-descrittivi. Ciò vale sia per l’invio che per la ricezione dei dati REST. Ogni rappresentazione deve descrivere il proprio formato di dati. Quindi, se stai ricevendo JSON, il messaggio di risposta avrà il suo tipo di media impostato su JSON. Senza queste informazioni, i dati non possono essere analizzati in modo affidabile.
    4. Motore Hypermedia per gli stati dell’applicazione. Un’interfaccia uniforme deve utilizzare Hypermedia come motore dello stato dell’applicazione. Questo è un modo complicato per dire che una volta che il client ha accesso a una risorsa REST, dovrebbe essere in grado di scoprire tutte le risorse e i metodi disponibili attraverso i collegamenti ipertestuali forniti. Se viene richiesta una pagina (una risorsa), la rappresentazione di ritorno dovrebbe includere collegamenti ipertestuali a tutte le risorse e metodi disponibili.

    Se e solo se un’API basata sul web soddisfa questi sei vincoli, può essere considerata un’API REST.

    REST API e HTTP

    Lavorando con le API REST, molto probabilmente invierai le tue richieste tramite HTTP. Ciò significa che REST e HTTP sono intrinsecamente collegati? No, ma una grande percentuale di API REST è disponibile attraverso il web utilizzando il protocollo HTTP. Quindi sebbene non tutte le API REST utilizzino il protocollo HTTP, quelle RESTful lo fanno.

    Lasciatemi spiegare. HTTP, abbreviazione di HyperText Transfer Protocol, è il protocollo utilizzato dal browser Web per accedere ai documenti ipertestuali sul world wide web. Quel world wide web vive su internet insieme ad altri servizi come SMTP per email, vari servizi di instant messaging, streaming video e così via. Come hai già appreso, REST è un insieme di sei vincoli di progettazione dell’architettura software che producono un tipo specifico di servizio. Non c’è nulla in quella definizione di REST che stabilisce che il servizio deve essere eseguito su HTTP e quindi sul web. Si potrebbe facilmente fare un servizio REST in esecuzione su FTP o SMTP o qualche altro protocollo. REST e HTTP non sono collegati; sono solo un accoppiamento conveniente.

    Quando un servizio REST viene eseguito su Internet via HTTP per darci accesso a una risorsa Web, viene chiamata API RESTful. La piattaforma web è ciò che rende RESTful un servizio. In altre parole, se si invia una richiesta tramite HTTP a un servizio REST che soddisfa i sei vincoli, tale servizio è un’API RESTful.

     

    Giulio Cantali – IT Consultant

    Creatore di Database Master, il primo percorso per diventare esperti di database

Lascia un commento

Se vuoi condividere la tua opinione, lascia un commento

Puoi usare questi tag e attributi: HTML:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">