Che cos’è REST?

REpresentational State Transfer

REST, o REpresentational State Transfer, è uno stile architettonico per fornire standard tra sistemi informatici sul web, rendendo più facile per i sistemi di comunicare tra loro. I sistemi REST-compliant, spesso chiamati sistemi RESTful, sono caratterizzati dal modo in cui sono stateless e separano le preoccupazioni di client e server. Andremo in che cosa significano questi termini e perché sono caratteristiche benefiche per i servizi sul Web.,

Separazione di Client e Server

Nello stile architettonico REST, l’implementazione del client e l’implementazione del server possono essere eseguite in modo indipendente senza che ciascuno sappia dell’altro. Ciò significa che il codice sul lato client può essere modificato in qualsiasi momento senza influire sul funzionamento del server e il codice sul lato server può essere modificato senza influire sul funzionamento del client.

Finché ogni lato sa quale formato di messaggi inviare all’altro, possono essere mantenuti modulari e separati., Separando i problemi dell’interfaccia utente dai problemi di archiviazione dei dati, miglioriamo la flessibilità dell’interfaccia tra le piattaforme e miglioriamo la scalabilità semplificando i componenti del server. Inoltre, la separazione consente a ciascun componente la capacità di evolversi in modo indipendente.

Utilizzando un’interfaccia REST, client diversi raggiungono gli stessi endpoint REST, eseguono le stesse azioni e ricevono le stesse risposte.,

Statelessness

I sistemi che seguono il paradigma REST sono stateless, il che significa che il server non ha bisogno di sapere nulla sullo stato in cui si trova il client e viceversa. In questo modo, sia il server che il client possono comprendere qualsiasi messaggio ricevuto, anche senza vedere i messaggi precedenti. Questo vincolo di apolidia viene applicato attraverso l’uso di risorse, piuttosto che comandi. Le risorse sono i nomi del Web: descrivono qualsiasi oggetto, documento o cosa che potrebbe essere necessario archiviare o inviare ad altri servizi.,

Poiché i sistemi REST interagiscono attraverso operazioni standard sulle risorse, non si basano sull’implementazione di interfacce.

Questi vincoli aiutano le applicazioni RESTful a raggiungere affidabilità, prestazioni rapide e scalabilità, come componenti che possono essere gestiti, aggiornati e riutilizzati senza influire sul sistema nel suo complesso, anche durante il funzionamento del sistema.

Ora, esploreremo come la comunicazione tra il client e il server avviene effettivamente quando stiamo implementando un’interfaccia RESTful.,

Comunicazione tra Client e server

Nell’architettura REST, i client inviano richieste per recuperare o modificare le risorse e i server inviano risposte a queste richieste. Diamo un’occhiata ai modi standard per effettuare richieste e inviare risposte.

Effettuare richieste

REST richiede che un client effettui una richiesta al server per recuperare o modificare i dati sul server.,lient per fornire informazioni su richiesta

un percorso di una risorsa

corpo del messaggio facoltativo contenenti dati

HTTP Verbi

Ci sono 4 base verbi HTTP usiamo nelle richieste di interagire con le risorse di un sistema RIPOSO:

• GET — recuperare una specifica risorsa (id) o un insieme di risorse
• POST — creare una nuova risorsa
• PUT — aggiornamento di una specifica risorsa (id)
• elimina — per ELIMINARE una risorsa specifica da id

Si può imparare di più su questi HTTP verbi del Codecademy articolo:

• Quello che è il CRUD?,

Intestazioni e parametri di accettazione

Nell’intestazione della richiesta, il client invia il tipo di contenuto che è in grado di ricevere dal server. Questo è chiamato il campo Accept e garantisce che il server non invii dati che non possono essere compresi o elaborati dal client. Le opzioni per i tipi di contenuto sono Tipi MIME (o estensioni di posta Internet multiuso, che puoi leggere di più nei documenti Web MDN.,

I tipi MIME, utilizzati per specificare i tipi di contenuto nel campoAccept, sono costituiti da untype e da unsubtype. Sono separati da una barra ( / ).

Ad esempio, un file di testo contenente HTML verrebbe specificato con il tipo text/html. Se questo file di testo conteneva invece CSS, sarebbe specificato come text/css. Un file di testo generico sarebbe indicato come text/plain. Questo valore predefinito, text/plain, non è un catch-all, tuttavia., Se un client si aspetta text/csse riceve text/plain, non sarà in grado di riconoscere il contenuto.

Altri tipi comunemente usati e sottotipi:

Per esempio, un client di accedere a una risorsa con id 23 in un articles risorse su un server può inviare una richiesta come questa:

Accept campo di intestazione in questo caso è detto che il cliente assume il contenuto in text/html o application/xhtml.,

Percorsi

Le richieste devono contenere un percorso di una risorsa su cui deve essere eseguita l’operazione. Nelle API RESTful, i percorsi dovrebbero essere progettati per aiutare il cliente a sapere cosa sta succedendo.

Convenzionalmente, la prima parte del percorso dovrebbe essere la forma plurale della risorsa. Ciò mantiene i percorsi nidificati semplici da leggere e facili da capire.

Un percorso comefashionboutique.com/customers/223/orders/12 è chiaro a cosa punta, anche se non hai mai visto questo percorso specifico prima, perché è gerarchico e descrittivo., Possiamo vedere che stiamo accedendo all’ordine con id 12 per il cliente con id

I percorsi dovrebbero contenere le informazioni necessarie per individuare una risorsa con il grado di specificità necessario. Quando si fa riferimento a un elenco o una raccolta di risorse, non è sempre necessario aggiungere un id. Ad esempio, una richiesta POST al percorso fashionboutique.com/customers non richiede un identificatore aggiuntivo, poiché il server genererà un id per il nuovo oggetto.,

Se stiamo cercando di accedere a una singola risorsa, dovremmo aggiungere un id al percorso.Ad esempio:GET fashionboutique.com/customers/:id — recupera l’elemento nella risorsa customers con id specificato.DELETE fashionboutique.com/customers/:id — elimina l’elemento nella risorsacustomers conid specificato.,

Invio di risposte

Tipi di contenuto

Nei casi in cui il server invia un payload di dati al client, il server deve includere uncontent-type nell’intestazione della risposta. Questo campo di intestazionecontent-type avvisa il client del tipo di dati che sta inviando nel corpo della risposta. Questi tipi di contenuto sono Tipi MIME, proprio come sono nel campoaccept dell’intestazione della richiesta., Il content-typeche il server restituisce nella risposta deve essere una delle opzioni specificate dal client nel campoaccept della richiesta.,

Per esempio, quando un client accede a una risorsa con id 23 in un articles risorsa con questa Richiesta GET:

Il server può inviare il contenuto con l’intestazione di risposta:

Questo significa che il contenuto richiesto è di essere di ritorno nella risposta del corpo con un content-type di text/html, che il cliente ha detto che sarebbe in grado di accettare.,

Codici di risposta

Le risposte dal server contengono codici di stato per avvisare il client di informazioni sul successo dell’operazione. Come sviluppatore, non è necessario conoscere ogni codice di stato (ci sono molti di loro), ma si dovrebbe conoscere le più comuni e come essi vengono utilizzati:

Per ogni verbo HTTP, ci sono attesi i codici di stato di un server dovrebbe tornare al successo:

• OTTENERE ritorno 200 (OK)
• POST — ritorno 201 (CREATO)
• METTERE il ritorno di 200 (OK)
• ELIMINA — ritorno 204 (SENZA CONTENUTO)Se l’operazione ha esito negativo, il ritorno più specifiche stato possibile il codice corrispondente al problema che si è verificato.,

Esempi di richieste e risposte

Supponiamo di avere un’applicazione che consente di visualizzare, creare, modificare ed eliminare clienti e ordini per un piccolo negozio di abbigliamento ospitato sufashionboutique.com. Si potrebbe creare un’API HTTP che consente a un client di eseguire le seguenti funzioni:

Se si desidera visualizzare tutti i clienti, la richiesta sarebbe simile a questa:

Una possibile risposta intestazione sarebbe simile:

seguito da customers dati richiesti nel application/json formato.,

Creare un nuovo cliente inviando i dati:

Il server genera quindi un id per l’oggetto e lo restituisce al client, con un header:

Per visualizzare un singolo cliente, abbiamo capito, specificando l’id del cliente:

Una possibile risposta intestazione sarebbe simile:

quindi i dati per il customer risorsa id 23 application/json formato.,

Possiamo aggiornare quel cliente inserendo i nuovi dati:

Una possibile intestazione di risposta avrebbeStatus Code: 200 (OK), per notificare al cliente che l’articolo conid 123 è stato modificato.

Si può anche ELIMINARE il cliente, specificando il suo id:

La risposta sarebbe un header contenente Status Code: 204 (NO CONTENT), avvisare il cliente che l’elemento id 123 è stato eliminato, e nulla nel corpo.,

Pratica con REST

Immaginiamo di costruire un sito di raccolta di foto. Vogliamo creare un’API per tenere traccia di utenti, luoghi e foto di tali luoghi. Questo sito ha unindex.html e unstyle.css. Ogni utente ha un nome utente e una password. Ogni foto ha una sede e un proprietario (cioè l’utente che ha scattato la foto). Ogni sede ha un nome e un indirizzo.,d=”229c60b6ce”>

Request-POST /venuesResponse-201 (CREATED)Content-type: application/json

Request-POST /venues/:id/photosResponse-201 (CREATED)Content-type: application/json

PUT Requests

Request-PUT /users/:idResponse-200 (OK)

Request-PUT /venues/:idResponse-200 (OK)

Request-PUT /venues/:id/photos/:idResponse-200 (OK)

DELETE Requests

Request-DELETE /venues/:idResponse-204 (NO CONTENT)

Request-DELETE /venues/:id/photos/:idResponse-204 (NO CONTENT)