Richieste

Finora abbiamo utilizzato solo richieste di tipo GET ma esistono differenti tipi di richieste.

Una richiesta è una domanda, un'interrogazione, al server che viene effettuata mediante apposite interfacce utente.

Le "interrogazioni" partono da un client (un sito web, un app ecc.) e sono indirizzate verso un server da cui ci si attende una risposta.

Un interrogazione verso il server può richiedere qualcosa come: una risorsa in generale (file statici o dati JSON) o il risultato di una elaborazione.

Il risultato di un'elaborazione è il frutto dei dati passati all'interno della nostra richiesta.

Questo tipo di richieste contengono dati/informazioni che vogliamo che siano elaborate dal server all'interno della QUERY-STRING o nel BODY DELLA REQUEST stessa.

Il body della richiesta ( letteralmente corpo della richiesta) é "uno spazio" che contiene dati da elaborare.

endpoint

Tutte le richieste devono essere indirizzate verso un punto preciso; questo punto è chiamato "endpoint" è rappresenta un indirizzo web specifico.

Un indirizzo specifico può essere un url assoluto:

https://www.cinquepuntozero.it/

un url relativo:

https://www.cinquepuntozero.it/articoli/
https://www.cinquepuntozero.it/articoli/programmazione/
https://www.cinquepuntozero.it/articoli/programmazione/node/

o un url assoluto e/o relativo che accetta query:

https://www.cinquepuntozero.it/ricerca/
https://www.cinquepuntozero.it/ricerca?query=qualcosa

In realtà questa distinzione è puramente concettuale tutte le tipologie di url possono essere utilizzate come endpoint; a decidere se e come un url possa gestire una "query" ed in generale il suo funzionamento è lo sviluppatore stesso backend dell'API di dialogo con il server.
Lo sviluppatore deciderà se una richiesta verso un indirizzo specifico possa restituire una risorsa, come nel caso dei file statici, un risultato "precompilato" o possa gestire una elaborazione di dati inviati mediante query o body della richesta.

Tipi di richieste

Come precedentemente accennato esistono differenti tipologie di richieste, utili, per differenti scopi.

L'insieme di tutte le tipologie di richieste è identificato sotto l'acronimo di CRUD: Create, Read, Update e Delete.

Metodo	CRUD
GET	Read
POST	Create
PUT	Update
DELETE	Delete

L'insieme di tutti i metodi definiscono quelli che sono chiamati "verbi delle richieste HTTP".
I verbi HTTP comunicano al server cosa fare con i dati identificati.

La prima distinzione da effettuare per comprendere il loro funzionamento è tra le richieste : GET e POST.

GET	i dati della richiesta sono visibili nell'url all'interno della query-string sotto forma di coppie paramentro-valore
POST	i dati della richiesta sono nascosti e contenuti all'interno della body della richiesta stessa; possono essere dati di tipo JSON, XML, TXT ecc.

Se lavoriamo con dati sensibili come ad esempio dati dell'utente, codici fiscali, dati bancari ecc. la scelta più opportuna è lavorare con richieste di tipo POST; se invece lavoriamo con dati che in linea generale servono alla meccanica stessa della nostra app/sito e non contengono dunque dati sensibili dell'utente o del sito, la scelta più indicate e più largamente diffusa e quella di lavorare con richieste di tipo GET.

GET

Le richieste di tipo GET lavorano esclusivamente con le query-string e con le coppie "parametro-valore".

In genere utilizzate per prendere "GET", richiedere un informazione.

Quando ci colleghiamo ad un sito es. "https://www.cinquepuntozero.it/" stiamo effettuando una richiesta al server gestita mediante l'endpoint che è l'indirizzo stesso ovvero la root principale del sito.
Questo tipo di interrogazione ci restituisce il file "homepage.html".
Questo endpoint è l'esempio di una richiesta GET che restituisce semplicemente una risorsa, che è un file statico.

Se proviamo a effettuare una ricerca mediante la lente in alto a destra potremo osservare che, una volta inviata la ricerca, l'indirizzo cambia in "https://www.cinquepuntozero.it/?s=nodejs";

Lo stesso endpoint, gestisce la restituzione di una risorsa statica ed l'eventuali richiesta effettuate mediante query-string.

Se non includiamo alcuna query, ci restituisce il file statico della pagina, se inviamo una query "?s=nodejs", ci restituisce il risultato della ricerca che è l'elaborazione dei dati passati mediante la query stessa.

In Node.Js abbiamo già visto come gestire questo tipo di richieste come la restituzione di file statici, come gestire il routing mediante ROUTE PARAMS "request.params" ed elaborare richieste più complesse mediante gli URL PARAMS "request.query".

POST

Le richieste di tipo POST inviano informazioni di cui vogliamo effettuare la loro elaborazione mediante il BODY della richiesta stessa.

In genere utilizzate per inviare "POST", creare una informazioni, un dato.

Questa è una richiesta effettuata lato front-end mediante API Fetch:

fecth("https://www.cinquepuntozero.it/", {
    method: "post",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
       nome: "Mario",
       cognome: "Rossi"
    })
 });

Stiamo passando nel "Init Object" legato alla richiesta stessa una proprietà "body" che contiene un oggetto JSON che rappresenta il dato da passare.

Lato back-end non dovremmo preoccuparci di come è inviata una richiesta frontalmente ma dovremo occuparci di poterla gestire.

app.use(express.json());
app.post('/', function(request,response){
console.log(request.body);
response.send("Ricevuta correttamente richiesta POST");
});

con l'oggetto "request" e la sua proprietà "body" ("request.body") recuperiamo il contenuto, "corpo", della richiesta e con "response.send()" restituiamo una risposta.

Postman

Dovremmo aver notato da subito un ostacolo evidente, ovvero, essendo le richieste lato front-end abbastanza corpose, per effettuare il testing della gestione di queste richieste, dovremmo provvedere a costruire un infrastruttura front-end.
Ma il nostro compito in Node.js non è quello di realizzare infrastrutture front-end ma di creare la logica che è nel backend.

In soccorso ci viene incontro POSTMAN che è un software che consente di testare vari tipi di richieste senza l'utilizzo di un browser.

Quello che ci è restituito nella CLI di Node.JS, per effetto dell'istruzione "console.log(request.body);" si tratta dell'oggetto JSON passato all'interno della richiesta POST.

Ricevuto il nostro oggetto "request.body" possiamo utilizzarlo includendo delle operazioni da effettuare con esso all'interno della gestione della richiesta "app.post()".

Middleware di Express

Nell'esempio precedente abbiamo incluso nel nostro codice la riga:

...
app.use(express.json());
...

"express.json()" rappresenta un middleware nativo, built-in, di Express.
Il suo scopo è di interpretare correttamente i dati in entrata di tipo JSON.
se proviamo ad omettere la riga di codice, ovvero il middleware, quello che ci sarebbe restituito sarebbe il valore "undefined"; questo perchè il middleware verifica che il dato in ingresso sia un JSON, si occupa di come gestirlo e restituire il dato.

In Node.js quando abbiamo effettuato il routing di file statici abbiamo già utilizzato un middleware nativo di Express:

const express = require('express');
const app = express();

app.use(express.static('public'));

app.get('/', function(request, response) {
response.sendFile('homepage.html', {root: __dirname + '/public'});
})

"express.static()" ci consente di indicare da dove recuperare, ovveri da quale directory, i file statici.

Per chi ha competenze front-end potrebbe chiedersi quale senso abbia dichiarare un "header" della richiesta inviata; l'header della richiesta inviata indica un "informazione" utile per il debuging di cosa ci apprestiamo ad inviare.
Con i middleware di Express stiamo invece indicando, lato backend, cosa sostanzialmente siamo disponibili a gestire e cosa ci aspettiamo che ci venga inviato includendo anche la gestione vere e propria di ciò che è effettivamente stato ricevuto.

PUT & DELETE

Molto similmente al metodo "POST" nella loro strutture, i due metodi "PUT" e "DELETE", consentono di lavorare con i dati contenuti nel body della richiesta indirizzando le operazioni da effettuare differenziandole in base ai verbi HTTP.
Vedremo in concerto, nell'articolo successivo, come utilizzare i quattro metodi, all'interno di un semplice API di comunicazione con il server.