Parte 1: Cos'è REST In questa parte daremo uno sguardo più da vicino a come avviene la comunicazione tra il client e il server. Lungo il percorso riveleremo nuovi termini e ne forniremo le spiegazioni. Per rendere tutto (diventato) chiaro, analizzeremo la comunicazione client-server utilizzando l'esempio di alcune applicazioni RESTful. Diciamo che stiamo sviluppando un'applicazione web in grado di memorizzare informazioni sui clienti e sui loro ordini. Quelli. il nostro sistema è in grado di manipolare alcune entità: crearle, modificarle, cancellarle e fornire informazioni su di esse. Tali entità saranno:
clienti - clienti;
ordini - ordini dei clienti;
articoli - merci.
Nell'architettura REST, i client inviano richieste al server per ottenere o modificare dati e i server inviano risposte ai client alle loro richieste.
Richieste
Le richieste dei client vengono quasi sempre effettuate tramite HTTP. In generale, le richieste HTTP sono costituite da diversi componenti:
Metodo HTTP;
titolo;
URI;
corpo della richiesta.
Di seguito esamineremo ogni componente in modo più dettagliato.
URI e risorse
I dati che i client ottengono o modificano tramite richieste sono chiamati risorse. La base dell'interazione client-server è la manipolazione delle risorse. Le risorse in REST sono tutto ciò a cui è possibile assegnare un nome. In un certo senso, sono come le classi in Java. In Java possiamo creare una classe per qualsiasi cosa. È lo stesso in REST: una risorsa può essere qualsiasi cosa: un utente, un documento, un report, un ordine. Tutto ciò può essere un'astrazione di qualche entità o qualcosa di concreto, ad esempio un file: un'immagine, un video, un'animazione, un file PDF. Per il nostro esempio, abbiamo 3 risorse:
clienti - clienti;
ordini - ordini dei clienti;
articoli - merci.
I client inviano richieste ai cosiddetti endpoint, o endpoint. Per dirla in modo molto semplice, un endpoint è qualcosa come un indirizzo sulla rete. Per andare più in profondità, un endpoint è un URI : una sequenza di caratteri che identifica una risorsa astratta o fisica. Uniform Resource Identifier: un identificatore di risorsa unificato. A volte l'endpoint, o URI, è chiamato percorso, ovvero il percorso di una risorsa. Ai fini di questo articolo utilizzeremo il termine URI. Ogni risorsa specifica deve avere un URI univoco. La responsabilità di garantire che ogni risorsa abbia sempre il proprio URI ricade sulle spalle dello sviluppatore del server. Nel nostro esempio, siamo noi gli sviluppatori, quindi lo faremo nel modo in cui sappiamo. Così come in un database relazionale è spesso consuetudine impostare la chiave primaria su un determinato ID numerico, nel REST ogni risorsa ha un proprio ID. Accade spesso che l'ID di una risorsa in REST corrisponda all'ID del record nel database in cui sono archiviate le informazioni su questa risorsa. Gli URI REST di solito iniziano con la forma plurale di un sostantivo che descrive una risorsa. Ad esempio, dalla parola clienti. Successivamente, viene indicato un ID tramite una barra: l'identificatore di un client specifico. Esempi:
/clients - URI di tutti i client esistenti;
/clients/23 - URI di un client specifico, ovvero il client con ID=23;
/clients/4 - URI di un client specifico, ovvero il client con ID=4.
Ma non è tutto. Possiamo estendere l'URI aggiungendovi ordini:
/clients/4/orders — URI di tutti gli ordini del cliente n. 4;
/clients/1/orders/12 - URI dell'ordine n. 12 del cliente n. 1.
Se continuiamo questa catena e aggiungiamo beni, otteniamo:
/clients/1/orders/12/items — URI dell'elenco di tutti i prodotti nell'ordine n. 12 realizzato dal cliente n. 1.
Con i livelli di nidificazione, la chiave è rendere gli URI intuitivi.
Metodo HTTP
Il metodo HTTP (metodo HTTP inglese) è una sequenza di qualsiasi carattere, ad eccezione di controlli e separatori, che indica l'operazione principale su una risorsa. Esistono diversi metodi HTTP comuni. Elenchiamo quelli che più spesso vengono utilizzati nei servizi RESTful:
GET - utilizzato per ottenere informazioni su una risorsa specifica (tramite ID) o una raccolta di risorse;
POST - utilizzato per creare una nuova risorsa;
PUT - utilizzato per modificare una risorsa (tramite ID);
DELETE - utilizzato per eliminare una risorsa (tramite ID).
Intestazioni
Le richieste, così come le risposte, contengono intestazioni HTTP. Inviano informazioni aggiuntive sulla richiesta (o risposta). Le intestazioni sono coppie chiave-valore. Puoi leggere l'elenco delle voci più comuni nella pagina Wikipedia . Con REST, i client possono spesso inviare un'intestazione Accept nella loro richiesta al server. È necessario per far sapere al server in quale formato il client si aspetta di ricevere una risposta da esso. Varie opzioni di formato sono presentate nella cosiddetta lista dei tipi MIME. MIME (Multifunction Internet Mail Extensions) è una specifica per la codifica delle informazioni e la formattazione dei messaggi in modo che possano essere inviati su Internet. Ogni tipo MIME è costituito da due parti, separate da una barra: un tipo e un sottotipo. Esempi di tipi MIME per diversi tipi di file:
In totale, la richiesta può avere la seguente intestazione:
Accept:application/json
Questa intestazione indica al server che il client si aspetta di ricevere una risposta in formato JSON.
Richiedi corpo
Un messaggio inviato dal client al server. Il fatto che una richiesta abbia o meno un corpo dipende dal tipo di richiesta HTTP. Ad esempio, le richieste GET e DELETE in genere non contengono alcun corpo della richiesta. Ma PUT e POST possono contenere: è tutta una questione di scopo funzionale del tipo di richiesta. Dopotutto, per ricevere dati ed eliminarli tramite ID (che viene trasmesso nell'URL), non è necessario inviare dati aggiuntivi al server. Ma per creare una nuova risorsa (richiesta POST), è necessario trasferire questa risorsa. Lo stesso vale per la modifica di una risorsa esistente. In REST, i formati XML o JSON vengono spesso utilizzati per trasmettere il corpo della richiesta. Il formato più comune è JSON. Supponiamo di voler inviare una richiesta al server e in essa creare una nuova risorsa. Se ricordi, ad esempio abbiamo esaminato un'applicazione che gestisce gli ordini dei clienti. Diciamo che vogliamo creare un nuovo client. Nel nostro caso, memorizziamo le seguenti informazioni sui clienti: Nome Email Numero di telefono Quindi il corpo di tale richiesta potrebbe essere il seguente JSON:
Modifica il cliente n. 1 come segue:
Nome - Ben
Email - bigben@jr.com
Tel. — +380 (190) 346-42-13
DELETE /clients/12/orders/6
Elimina l'ordine n. 6 dal cliente n. 12 dal sistema
Risposte
Diciamo alcune parole sulle risposte del server. La risposta solitamente è composta dalle seguenti parti:
Codice di risposta;
intestazioni;
corpo della risposta.
In generale, le intestazioni di risposta non sono molto diverse dalle intestazioni di richiesta. Inoltre, alcune intestazioni vengono utilizzate sia nelle risposte che nelle richieste. Penso che tutto sia chiaro anche con il corpo della risposta. Il corpo spesso restituisce le informazioni richieste dal cliente. Le informazioni possono essere restituite nello stesso formato JSON per le richieste GET. Ma l’ultima parte è un po’ più interessante.
Codici di risposta HTTP
Diamo uno sguardo più da vicino ai codici di risposta HTTP. Ecco una citazione da Wikipedia: Il codice di stato HTTP fa parte della prima riga della risposta del server per le richieste tramite il protocollo HTTP. È un numero intero con tre cifre decimali. La prima cifra indica la classe della condizione. Il codice di risposta è solitamente seguito da una frase esplicativa in inglese separata da uno spazio, che spiega alla persona il motivo di quella particolare risposta. Esempi:
201 Creato;
401 Non autorizzato;
507 Spazio di archiviazione insufficiente.
Il client apprende dal codice di risposta sui risultati della sua richiesta e determina quali azioni intraprendere successivamente. I codici di risposta sono divisi in diversi gruppi:
1ХХ - informativo;
2ХХ - informare sui casi di accettazione ed elaborazione con successo della richiesta del cliente;
3XX - informa il client che per portare a termine con successo l'operazione è necessario effettuare un'altra richiesta, solitamente utilizzando un URI diverso;
4ХХ - errore del client. Ad esempio, una richiesta costruita in modo errato o il noto codice 404 Not Found, che può verificarsi quando un client richiede una risorsa inesistente;
5ХХ - errore del server. Restituito al client se l'operazione fallisce a causa di un errore del server.
GO TO FULL VERSION