Cos'è un'API REST?

Le API sono diventate il metodo più comune di interazione tra programmi e dispositivi nel computing moderno. Un'API è un insieme di regole che definisce il modo in cui i programmi possono connettersi e comunicare tra loro. Come si intuisce dal nome, un’API REST trasferisce su ogni richiesta lo stato di una transazione. Questo approccio presenta vantaggi a livello di progettazione, performance e risorse rispetto agli altri. L’architettura REST è stata sviluppata per più di vent’anni ed è molto diffusa nelle architetture basate sui servizi e distribuite.

Uno dei concetti fondamentali delle API REST sono le risorse. Una risorsa è un oggetto con un tipo, dei dati associati, delle relazioni con altre risorse e un insieme di metodi che operano su di essa. È un concetto molto simile a quello di oggetto nella programmazione, anche se presenta solo alcuni metodi standard: HTTP GET, POST, PUT e DELETE. Le risorse possono esistere in autonomia o essere raggruppate in raccolte che sono esse stesse risorse.

Nel computing moderno, un modello comune - fondamentale anche per le API REST - è il client-server, dove un client che ha bisogno di una risorsa individua e comunica con un server che può fornirla. Praticamente tutto il traffico Cloud è gestito con questo approccio, perché in questo modo si usufruisce della massima flessibilità possibile per consentire a più clienti di accedere a diversi server. Questo principio funziona anche per le architetture serverless, in cui un service broker prende il posto di un server conosciuto dal cliente.

L'architettura REST ha iniziato a svilupparsi nel 1993, quando sono apparsi i primi siti per uso generale.

La rapida espansione del Web ha portato a diverse proposte di estensioni del protocollo originale, HyperText Transfer Protocol (HTTP). Il World Wide Web Consortium (W3C) e l'Internet Engineering Task Force (IETF) hanno iniziato a valutare e formalizzare nuove versioni di HTTP, l’Hyper Text Transfer Language (HTML) e gli standard URI.

Dopo aver lavorato per sei anni alla standardizzazione di HTTP e URI, nel 2000 il ricercatore Roy Fielding ha definito l’approccio REST, impostando lo stile di architettura necessario a verificare i futuri sviluppi dei protocolli Web e a identificare le estensioni che non erano adatte agli obiettivi di comportamento e di performance del Web.

Successivamente, i principi dell’architettura REST si sono rivelati ben adattabili all'evoluzione del connected computing. Nel 2015, l'Iniziativa OpenAPI, con il patrocinio della Linux Foundation e i suoi membri, come Google, IBM, Microsoft e PayPal, ha creato l’OpenAPI Specification basata sulle regole RESTful, che pubblica file di interfaccia leggibili da macchine per descrivere, produrre, utilizzare e visualizzare i servizi Web RESTful.

Le applicazioni implementate sulla base dei file di interfaccia OpenAPI possono generare automaticamente la documentazione di metodi, parametri e modelli. Oltre a fornire orientamenti di settore per header standardizzati, codici, descrizioni delle risorse e future innovazioni, l'iniziativa OpenAPI fornisce strumenti, materiali di riferimento e buone pratiche. Questi fattori sono particolarmente importanti per creare, verificare e utilizzare correttamente l’autenticazione e la sicurezza dei dati in modalità RESTful, su cui l’Iniziativa OpenAPI si concentra.

1. Interfaccia uniforme

Tutte le richieste effettuate tramite un’API REST devono rispettare le regole di formattazione di quell’API. Indipendentemente dal client che sta effettuando la richiesta, le informazioni devono trovarsi dove qualsiasi altro client le metterebbe. Un esempio è l'URL (Uniform Resource Locator), utilizzato per identificare le risorse tramite HTTP, che è un esempio di Uniform Resource Identifier (URI) che può avere una portata più ampia.

2. Separazione client-server

Le API REST richiedono che le applicazioni client e server siano completamente indipendenti l'una dall'altra. Il client deve conoscere solo il nome completo della risorsa richiesta nello spazio virtuale consentito dall'API. Altrimenti, le uniche informazioni che client e server hanno l'uno dell'altro sono quelle scambiate tramite le transazioni API.

3. Stateless

Ogni richiesta client deve contenere tutte le informazioni necessarie per elaborarla e il server non è tenuto a conservare alcuna informazione su tale richiesta una volta ricevuta. Non esiste un concetto di sessione nella progettazione dell'API REST e il server è stateless rispetto ad un particolare client.

4. Disponibilità in cache

A differenza della condizione stateless del server per ogni client, le risorse devono poter essere memorizzate nella cache in uno o più punti nel client e server, oppure tra di essi. Nel caso del server, se una particolare risorsa è stata fornita ed è probabile che venga richiesta nuovamente entro un certo periodo di tempo, dovrebbe essere messa in cache per ottenere una risposta più rapida. Il cliente deve prendere una decisione simile riguardo alle risorse ricevute. È necessario che il server indichi, tramite API, se una risorsa può essere messa in cache localmente e in sicurezza dal client, inclusa, se necessario, la durata di vita dei dati. La progettazione della cache, sebbene non faccia parte delle specifiche di una API RESTful, è fondamentale per garantire prestazioni elevate. I progettisti di API dovrebbero essere consapevoli di come questi principi si applichino concretamente.

5. Architettura di sistema a livelli

Una conseguenza della separazione client-server, della condizione stateless e della memorizzazione nella cache è che un client non può capire se sta comunicando direttamente con un server che detiene una particolare risorsa o con un intermediario come un service broker, un load balancer, un sistema di distribuzione dei contenuti o un altro sottosistema più vicino al client del server. In questo modo, chi progetta sistemi e infrastrutture dispone di una notevole flessibilità per massimizzare l'efficienza e l'affidabilità delle richieste soddisfatte in tutte le infrastrutture via cavo e wireless. Si tratta della base della funzionamento dell’edge computing.

6. Codice on demand

Mentre le API REST possono e spesso forniscono dati solo per il consumo del client, è sempre più frequente che il codice venga eseguito sul client, come gli oggetti Java o le applicazioni Web Javascript. Se implementato, il codice può essere eseguito solo su richiesta del client.

Le API REST possono gestire praticamente qualsiasi richiesta di accesso, formato di dati, controllo delle risorse o messaggi di stato, ma la condizione stateless implica che ogni richiesta debba contenere ogni autenticazione necessaria per verificarla, la definizione precisa della risorsa richiesta e l'azione esatta che viene richiesta.

Ad esempio, un'API di un file di sistema non RESTful può rispondere a una richiesta di lettura di un file restituendo un handle di file, un piccolo token assegnato a una sessione in modo che il client possa eseguire letture ripetute solo in riferimento a tale handle. Un'API REST dovrebbe invece inviare ogni volta non solo l'autorizzazione client, ma anche l'identificativo esatto della risorsa e la posizione precisa all'interno del file dei dati da leggere. È compito del cliente tenerne traccia.

Le API REST trasmettono tutte queste informazioni attraverso una combinazione di header e campi di parametri, e possono scambiare i dati in qualsiasi formato. Uno standard molto comune è JSON, il formato Javascript Object Notation, che può essere letto sia dagli umani che dalle macchine, a occhio nudo o utilizzando uno qualsiasi dei linguaggi di programmazione più diffusi.

Nella progettazione delle API REST è necessario considerarne l’efficacia, soprattutto quando si devono gestire grandi trasferimenti di dati o flussi critici a livello di tempo, oppure piccole quantità di dati provenienti da fonti con risorse limitate, come i sistemi IoT.

OVHcloud API è un servizio Web che consente ai clienti OVHcloud di acquistare, gestire, aggiornare e configurare i prodotti OVHcloud senza utilizzare l’interfaccia grafica del cliente. Basata sulle ultime API RESTful, questa soluzione permette di gestire quasi tutto l’universo OVHcloud. L'API è progettata per essere semplice e di facile utilizzo, e i frammenti di codice sono disponibili in diverse lingue.

Lo Spazio Cliente (V6) è ora accessibile tramite OVHcloud API. Ogni nuovo prodotto e le relative versioni includeranno la compatibilità con le API. La console API Explorer permette di esplorare le API per scoprire tutte le funzioni disponibili dei prodotti OVHcloud, anche per i clienti non registrati come sviluppatori. È anche possibile selezionare un prodotto e utilizzare l'API dedicata per scoprire le azioni correlate.

L’API RESTful di OVHcloud consente di sviluppare rapidamente e con agilità script per funzioni personalizzate, l’automazione, operazioni multiple simultanee e di creare strumenti di deploy e gestione IaaS o PaaS. Il supporto per il linguaggio esplicito è disponibile per C, C++, C#, Java, Perl, PHP, Python e Ruby e molti altri.