Cos'è RESTful API?

RESTful API è un'interfaccia utilizzata da due sistemi informatici per scambiare informazioni in modo sicuro su Internet. La maggior parte delle applicazioni aziendali deve comunicare con altre applicazioni interne e di terze parti per eseguire varie attività. Ad esempio, per generare buste paga mensili, il sistema di contabilità interna deve condividere i dati con il sistema bancario del cliente per automatizzare la fatturazione e comunicare con un'applicazione interna delle presenze. Le API RESTful supportano questo scambio di informazioni perché seguono standard di comunicazione software sicuri, affidabili ed efficienti.

Cos'è un'API?

Un'interfaccia del programma dell’applicazione (API) definisce le regole da seguire per comunicare con altri sistemi software. Gli sviluppatori espongono o creano API così che altre applicazioni possano comunicare con le proprie programmaticamente. Ad esempio, l’applicazione delle presenze espone un'API che chiede il nome completo dell’impiegato e un intervallo di date. Quando riceve queste informazioni, processa internamente le presenze dell’impiegato e dà come risultato il numero di ore lavorate in quell'intervallo di date.

Si può pensare all’API web come un gateway tra client e risorse nel web.

Client

I client sono utenti che vogliono accedere alle informazioni dal web. Il client può essere una persona o un sistema software che utilizza l’API. Ad esempio, gli sviluppatori possono scrivere programmi che accedono a dati meteo da un sistema meteo. Oppure è possibile accedere agli stessi dati dal proprio browser quando si visita direttamente il sito web del meteo.

Risorse

Le risorse sono le informazioni che le varie applicazioni forniscono ai propri client. Le risorse possono essere immagini, video, testi, numeri o qualsiasi tipo di dati. La macchina che fornisce le risorse al client è chiamata anche server. Le organizzazioni utilizzano le API per condividere risorse e fornire servizi Web garantendo sicurezza, controllo e autenticazione. Inoltre, le API le aiutano a determinare quale client esegue l'accesso a determinate risorse interne.

Costruire API con Amazon API Gateway

Cos'è REST?

Representiational State Transfer (REST) è un’architettura software che impone condizioni sul funzionamento di un'API. REST è stata inizialmente creata come linea guida per la gestione delle comunicazioni in una rete complessa come internet. Si può utilizzare l’architettura REST per supportare una comunicazione su vasta scala ad elevate prestazioni e affidabile. Si può facilmente implementare e modificare, apportando visibilità e portabilità multipiattaforma a qualsiasi sistema API.

Gli sviluppatori API possono progettare API utilizzando diverse architetture. Le API che seguono lo stile architetturale REST sono chiamate API REST. I servizi Web che implementano le architetture REST sono chiamati servizi Web RESTful. Il termine RESTful API si riferisce generalmente alle API web RESTful. Comunque, è possibile utilizzare i termini REST API e RESTful API in maniera interscambiabile.

Di seguito sono illustrati alcuni dei principi dello stile architetturale REST:

Interfaccia uniforme

L’interfaccia uniforme è fondamentale per la progettazione di qualsiasi servizio web RESTful. Fa riferimento al fatto che il server trasferisce informazioni in un formato standard. La risorsa formattata viene chiamata rappresentazione in REST. Questo formato può essere diverso dalla rappresentazione interna della risorsa nell’applicazione del server. Ad esempio, il server può archiviare dati come testo ma inviarli in un formato di rappresentazione HTML.

L’interfaccia uniforme impone quattro vincoli architetturali:

  1. Le richieste devono identificare le risorse. utilizzando un identificatore di risorse uniforme.
  2. I client hanno abbastanza informazioni nella rappresentazione della risorsa per modificarla o eliminarla se lo desiderano. Il server soddisfa questa condizione inviando metadati che descrivono ulteriormente la risorsa.
  3. I client ricevono informazioni su come elaborare ulteriormente la rappresentazione. Il server riesce nell'intento inviando messaggi auto-descrittivi che contengono metadati su come il client può utilizzarli al meglio.
  4. I client riceve informazioni su tutte le altre risorse correlate necessarie a completare un'attività. Il server riesce nell'intento inviando collegamenti ipertestuali nella rappresentazione così che i client possano scoprire in modo dinamico ulteriori risorse.

Apolidia

Nell’architettura REST, l’apolidia si riferisce ad un metodo di comunicazione in cui il server completa ogni richiesta del client indipendentemente da tutte le richieste precedenti. I client possono richiedere risorse in qualsiasi ordine e ogni richiesta è senza stato o isolata da altre richieste. Questi vincoli di progettazione di REST API implicano che il server può ogni volta comprendere e soddisfare del tutto la richiesta. 

Sistema a livelli

In un’architettura di sistema a livelli, il client non può connettersi ad altri intermediari autorizzati tra client e server, e riceverà ancora risposta dal server. I server possono anche trasmettere le richieste ad altri server. Si può progettare il proprio servizio Web RESTful per eseguire diversi server con numerosi livelli come sicurezza, applicazione e logica aziendale, che collaborano per soddisfare le richieste del client. Questi livelli rimangono invisibili al client.

Cacheability

I servizi Web RESTful supportano il caching, ossia il processo di archiviazione di alcune risposte nel client o in un intermediario per migliorare il tempo di risposta del server. Ad esempio, supponiamo di visitare un sito web con immagini header e footer comuni su ogni pagina. Ogni volta che si visita una nuova pagina del sito web, il server deve rinviare le stesse immagini. Per evitare ciò, il client salva nella cache o archivia queste immagini dopo la prima risposta e utilizza le immagini direttamente dalla cache. I servizi Web RESTful controllano il caching utilizzando le risposte API che si definiscono cacheabili o non cacheabili.

Codice on demand

Nello stile architetturale REST, i server possono estendere o personalizzare temporaneamente la funzionalità del client trasferendo il codice di programmazione del software al client. Ad esempio, quando si compila un modulo di registrazione su un sito web, il proprio browser evidenzia immediatamente qualsiasi errore compiuto, come numeri di telefono sbagliati. Ciò è possibile grazie al codice inviato dal server.

Quali sono i vantaggi delle API RESTful?

Le API RESTful includono i seguenti vantaggi:

Scalabilità

I sistemi che implementano le API REST possono dimensionare efficientemente perché REST ottimizza le interazioni client-server. L’apolidia rimuove il carico del server perché quest'ultimo non deve mantenere le vecchie informazioni di richiesta del client. Il caching ben gestito elimina parzialmente o completamente alcune interazioni client-server. Tutte queste caratteristiche supportano la scalabilità senza causare difficoltà di comunicazione in grado di ridurre le prestazioni.

Flessibilità

I servizi Web RESTful supportano la separazione completa client-server. Essi semplificano e dissociano varie componenti server così che ogni parte possa evolversi in modo indipendente. Modifiche della piattaforma o della tecnologia all’applicazione del server non influiscono sull’applicazione del client. La possibilità di stratificare le funzioni dell’applicazione aumenta ulteriormente la flessibilità. Ad esempio, gli sviluppatori possono apportare modifiche al livello di database senza riscrivere la logica dell’applicazione.

Indipendenza

Le API REST sono indipendenti dalla tecnologia utilizzata. Si possono scrivere entrambe le applicazioni client e server in vari linguaggi di programmazione senza influire sulla progettazione dell'API. Si può anche modificare la tecnologia sottostante da entrambi i lati senza inficiare la comunicazione.

Come funzionano le API RESTful?

La funzione di base di una API RESTful è la stessa della navigazione su internet. Il client contatta il server utilizzando l’API quando richiede una risorsa. Gli sviluppatori API spiegano in che modo il client dovrebbe utilizzare l’API REST nella documentazione API dell’applicazione del server. Di seguito i passaggi generali per qualsiasi chiamata REST API:

  1. Il client invia una richiesta al server. Il client segue la documentazione API per formattare la richiesta in modo che il server comprenda.
  2. Il server autentica il client e conferma che ha il diritto di effettuare la richiesta.
  3. Il server riceve la richiesta e la elabora internamente.
  4. Il server risponde al client. La risposta contiene informazioni che rivelano al client se la richiesta è avvenuta correttamente. La risposta include inoltre qualsiasi informazione richiesta dal client.

La richiesta API REST e i dettagli della risposta variano leggermente in base a come gli sviluppatori progettano l'API.

Cosa contiene la richiesta del client RESTful API?

Le API RESTful necessitano di richieste che contengano le seguenti componenti fondamentali:

Identificatore unico di risorse

Il server identifica ogni risorsa con identificatori unici di risorse. Per i servizi REST, il server di solito esegue l’identificazione della risorsa utilizzando un Uniform Resource Locator (URL). L’URL specifica il percorso alla risorsa. Un URL è simile all’indirizzo del sito web inserito nel browser per consultare qualsiasi pagina web. L’URL è anche detto endpoint di richiesta e specifica chiaramente al server ciò che il client richiede.

Metodo

Gli sviluppatori spesso implementano le API RESTful utilizzando l’Hypertext Transder Protocol (HTTP). Un metodo HTTP indica al server quello che è necessario fare alla risorsa. Di seguito, quattro comuni metodi HTTP:

GET

I client utilizzano GET per accedere alle risorse che sono collocate all’URL specifico nel server. Possono salvare nella cache le richieste GET e inviare i parametri nella richiesta di API RESTful per istruire il server a filtrare i dati prima di inviarli.

POST

I client utilizzano POST per inviare dati al server. Includono la rappresentazione dei dati con la richiesta. Inviare la stessa richiesta POST più volte ha l’effetto collaterale di creare la stessa risorsa più volte.

PUT

I client utilizzano PUT per aggiornare le risorse esistenti nel server. A differenza di POST, inviare la stessa richiesta PUT più volte in un servizio Web RESTful dà lo stesso risultato.

DELETE

I client utilizzano la richiesta DELETE per rimuovere la risorsa. Una richiesta DELETE può cambiare lo stato del server. Tuttavia, se l'utente non possiede un'autenticazione appropriata, la richiesta fallisce.

Header HTTP

Gli header di richiesta sono i metadati scambiati tra il client e il server. Ad esempio, l’header di richiesta indica il formato della richiesta e la risposta, fornisce informazioni sullo stato della richiesta e così via.

Dati

Le richieste API REST possono includere dati per POST, PUT e altri metodi HTTP per funzionare correttamente.

Parametri

Le richieste API RESTful possono includere parametri che forniscono al server più dettagli su ciò che deve essere fatto. Di seguito alcuni tipi di parametri:

  • I parametri di percorso che specificano i dettagli dell’URL.
  • I parametri query che richiedono più informazioni sulla risorsa.
  • I parametri cookie che autenticano rapidamente il client.

Cosa contiene la risposta del server RESTful API?

I principi REST richiedono che la risposta del server contenga le seguenti componenti principali:

Barra di stato

La barra di stato contiene un codice di stato di tre cifre che comunica se la richiesta è andata a buon fine o meno. Ad esempio, i codici 2XX indicano che la richiesta è andata a buon fine, mentre i codici 4XX e 5XX indicano errori. I codici 3XX indicano il reindirizzamento dell’URL.

Di seguito alcuni codici di stato comuni:

  • 200: Risposta di successo generica
  • 201: Risposta del metodo POST avvenuta con successo
  • 400: Richiesta errata che il server non può elaborare
  • 404: Risorsa non trovata

Corpo del messaggio

Il corpo della risposta contiene la rappresentazione della risorsa. Il server seleziona un formato di rappresentazione appropriato sulla base di ciò che contiene l’header della richiesta. I client possono richiedere informazioni in formati XML o JSON, che stabiliscono in che modo i dati sono scritti in testo semplice. Ad esempio, se il client richiede il nome e l’età di una persona di nome John, il server restituirà una rappresentazione JSON come segue:

'{"nome":"John", "età":30}'

Header

La risposta contiene inoltre header o metadati sulla risposta. Essi forniscono ulteriore contesto sulla risposta e includono informazioni come il server, la codifica, la data e il tipo di contenuti.

Cosa sono i metodi di autenticazione di RESTful API?

Un servizio Web RESTful deve autenticare le richieste prima che possa inviare una risposta. L'autenticazione è il processo di verifica di un'identità. Ad esempio, è possibile dimostrare la propria identità mostrando la carta di identità o la patente di guida. Allo stesso modo, i client del service RESTful devono dimostrare la propria identità al server per stabilire l'affidabilità.

L'API RESTful presentano quattro metodi di autenticazione comuni:

Autenticazione HTTP

L'HTTP definisce alcuni schemi di autenticazione che si possono utilizzare direttamente quando si stanno implementando API REST. Di seguito, due di questi schemi:

Autenticazione di base

Nell'autenticazione di base, il client invia l'user name e la password nell'header della richiesta. Essa li codifica con base64, una tecnica di encoding che converte la coppia in un set di 64 caratteri per la trasmissione sicura.

Autenticazione bearer

Il termine autenticazione bearer si riferisce al processo con cui si fornisce il controllo d'accesso al token bearer. Il token bearer è solitamente una stringa crittografata di caratteri che il server genera in risposta alla richiesta di login. Il client invia il token nell'header della richiesta per accedere alle risorse.

Chiavi API

Le chiavi API sono un'altra opzione per l'autenticazione delle API REST. In questo approccio il server assegna un valore unico generato ad un nuovo client. Quando il client tenta di accedere alle risorse, esso utilizza la chiave unica API per autoverificarsi. Le chiavi API sono meno sicure perché il client deve trasmettere la chiave, il che la rende vulnerabile al furto in rete.

OAuth

OAuth combina le password e i token per accessi login a qualsiasi sistema estremamente sicuri. Il server richiede prima una password e poi un altro token per completare il processo di autorizzazione. Può controllare il token in qualsiasi momento e nel corso del tempo con uno specifico margine e una specifica durata.

In che modo AWS fornisce il suo contributo nella gestione di API RESTful?

Amazon API Gateway è un servizio completamente gestito che semplifica per gli sviluppatori la creazione, la pubblicazione, la manutenzione, il monitoraggio e la protezione delle API su qualsiasi scala. API Gateway consente di creare API RESTful che rendono possibili applicazioni di comunicazione bidirezionale in tempo reale:

Utilizzando API Gateway, è possibile:

  • Fornire agli utenti prestazioni ad alta velocità sia per le richieste che per le risposte API.
  • Autorizzare l'accesso alle API con AWS Identity and Access Management (IAM) e Amazon. Cognito, i quali forniscono entrambi supporto OAuth nativo.
  • Con API Gateway è possibile eseguire simultaneamente più versioni della stessa API per iterare, testare e rilasciare rapidamente nuove versioni.
  • Monitora i parametri delle prestazioni e le informazioni sulle chiamate API, la latenza dati e la frequenza di errore dall'API Gateway. 

Inizia a utilizzare API Gateway con la nostra guida dettagliata e creando un account AWS oggi stesso.

Fasi successive delle reti informatiche di AWS

Scopri ulteriori risorse correlate al prodotto
Ulteriori informazioni sui servizi di rete 
Registrati e crea un account gratuito

Ottieni accesso immediato al Piano gratuito di AWS.

Registrati per il piano gratuito di API Gateway 
Inizia a costruire nella console

Inizia subito a costruire con Amazon Transcribe nella Console di gestione AWS.

Accedi