Introduzione all'API REST

Il primo modulo si è concluso con la creazione di una richiesta HTTP, l'invio e la ricezione di una risposta.

Lo faremo molte altre volte in futuro. Invieremo richieste a server di terze parti. Creeremo applicazioni che accettano tali richieste e restituiscono una risposta. Creeremo una logica complessa per elaborare le richieste.

Pertanto, è bene studiare a fondo tutto ciò che riguarda queste richieste, analizzandole in dettaglio. In modo da non limitarsi a copiare la richiesta da qualche parte e ripeterla, ma capire davvero come funziona il tutto.

Questo è ciò che faremo nel secondo modulo. Andiamo!

Informazioni generali

Iniziamo con le informazioni generali.

Se avete fatto i compiti nel primo modulo e avete studiato la documentazione, dovreste aver notato l'acronimo API. In realtà, è proprio la documentazione delle API la prima cosa che gli sviluppatori dovrebbero studiare se vogliono capire l'interazione con qualche servizio o applicazione in rete.

API

API - Application Programming Interface (Interfaccia di programmazione dell'applicazione). Si tratta di una descrizione dei modi in cui il client e il server possono comunicare tra loro. Apriamo la documentazione dell'API e impariamo da lì come ottenere i dati necessari dal server.

Vogliamo sempre che questa interazione sia semplice e comprensibile. Questo semplifica il compito sia degli sviluppatori (non è necessario reinventare la ruota quando si progetta un nuovo servizio) sia degli utenti (un servizio è molto più facile da imparare se funziona secondo lo stesso principio dei servizi già noti). E qui vale la pena ricordare un nuovo termine: REST.

REST

REST è l'acronimo di Representational State Transfer. Potrebbe non sembrare molto chiaro, ma in parole povere REST è uno stile di interazione (scambio di informazioni) tra un client e un server.

Non si tratta di un insieme rigido di regole e requisiti. REST non impone l'uso di un particolare linguaggio di programmazione, né si vincola a linee guida rigide. REST è chiamato stile architettonico e definisce 6 principi che l'architettura di un sistema deve rispettare.

Di conseguenza, un'API sviluppata tenendo conto dei principi di REST è chiamata API REST e le applicazioni stesse sono chiamate RESTful.

Creeremo proprio applicazioni RESTful di questo tipo, quindi vale la pena di discutere subito i principi a cui si conformeranno.

Principi RESTful

Modello client-server. Il principio definisce la separazione tra client e server, la differenziazione delle loro esigenze. Il client non deve preoccuparsi di come vengono memorizzati i dati, l'importante è che vengano rilasciati su richiesta. A sua volta, il server non si preoccupa di cosa il client farà con questi dati, di come elaborarli e visualizzarli. Questo permette ai due sistemi di svilupparsi indipendentemente l'uno dall'altro e migliora la scalabilità del sistema.

Statelessness. Questo principio significa che il server non deve "pensare" la risposta in base all'esperienza precedente con questo cliente. Ogni richiesta viene effettuata in modo tale da contenere tutte le informazioni necessarie alla sua elaborazione, indipendentemente dalle richieste precedenti.

Caching. Per ridurre al minimo i dati trasmessi, esiste un meccanismo di caching. Ad esempio, se in una pagina viene visualizzato un logo, non ha senso richiederlo ogni volta al server. Non cambia così spesso, sarà sufficiente ottenerlo una volta e salvarlo sul computer del client, nella cache. Ma se abbiamo bisogno di ottenere informazioni sulla velocità attuale dell'auto, la cache non sarà di alcun aiuto. Questo principio determina che i dati trasmessi dal server debbano essere designati come memorizzabili nella cache o meno.

Interfaccia uniforme. Questo principio definisce un unico formato di interazione tra client e server. La struttura di tutte le richieste deve essere la stessa. I dati devono essere inviati nella stessa forma, indipendentemente da chi li richiede.

Sistema a strati. Il client e il server non comunicano necessariamente in modo diretto. La trasmissione dei dati può passare attraverso diversi nodi intermedi. In questo caso, il sistema è progettato in modo che né il client né il server sappiano se stanno interagendo con l'applicazione finale o con un nodo intermedio. Ciò consente di bilanciare il carico sui server e di aumentare la scalabilità.

Codice su richiesta (opzionale). È l'unico principio non obbligatorio. In base ad esso, il client può espandere le proprie funzionalità scaricando codice eseguibile dal server (ad esempio, script). In questo caso, il codice deve essere eseguito solo su richiesta.