Introduzione al RIPOSO

8.1 Approccio API remoto

Tutti i programmatori commettono lo stesso errore quando creano un'architettura client-server. Cominciano a trattare le richieste al server come chiamate di metodo .

Vuoi avviare il processo di generazione del rapporto sul server, perché non inviargli una richiesta come:

http://server.com/startDocumentGeneration?params

E come scaricare il rapporto dopo che è stato completato? Per fare ciò, scriveremo un altro metodo:

http://server.com/getDocument

Il server memorizza HttpSessionle informazioni sul nostro documento e non appena il documento viene generato, il server lo restituirà.

Ottimo approccio. O no?

L'approccio è davvero terribile. Il fatto è che il server deve ricordare il numero del documento. In altre parole, per elaborare correttamente le nuove chiamate ai metodi, il server deve ricordare i risultati delle chiamate ai metodi precedenti.

Sul web, questo è un grosso problema. Internet potrebbe scomparire, il browser potrebbe chiudersi. La pagina può essere ricaricata o fare clic accidentalmente su un collegamento e così via. E il server continuerà a memorizzare megabyte di dati dalle precedenti richieste degli utenti ...

Per lavorare comodamente con il server, non puoi aspettarti di avere sempre a portata di mano i dati delle precedenti richieste al server.

Come allora chiamare i metodi del server? La risposta corretta sarebbe terribile: assolutamente no!

8.2 Approccio REST

I programmatori sono tornati alle origini e hanno ricordato che inizialmente la richiesta conteneva il percorso del file sul server:

http://server.com/path?params

E abbiamo deciso di utilizzare questo approccio al massimo.

Ora il server è considerato come un deposito di dati visibile all'esterno sotto forma di albero .

Se vuoi ottenere un elenco di tutti gli utenti, chiama la query:

http://server.com/users

Se desideri ottenere dati sull'utente 113, esegui la query:

http://server.com/users/113

E così via, tutto nella stessa vena.

Ancora una volta, il server è visto come un deposito di dati visibile all'esterno sotto forma di albero.

I dati possono essere ricevuti - richieste GET , modificate - richieste POST e cancellate - richieste DELETE .

8.3 Nessuno stato

Il protocollo REST di interazione tra il client e il server richiede la seguente condizione: durante il periodo tra le richieste del client, nessuna informazione sullo stato del client viene memorizzata sul server.

Tutte le richieste del client devono essere predisposte in modo tale che il server riceva ogni volta tutte le informazioni di cui ha bisogno per soddisfare la richiesta . Lo stato della sessione viene salvato sul lato client.

Durante l'elaborazione delle richieste del client, il client è considerato in uno stato di transizione. Ogni singolo stato dell'applicazione è rappresentato da collegamenti che possono essere richiamati al successivo accesso del client.

8.4 Uniformità dell'interfaccia

Tutti i percorsi utilizzati per recuperare gli oggetti dal server sono standardizzati. Questo è molto comodo, specialmente se stai ricevendo dati da altri server REST.

Tutte le interfacce oggetto devono soddisfare tre condizioni:

Identificazione delle risorse

Tutte le risorse sono identificate nelle richieste utilizzando un URI. Le risorse all'interno del server sono separate dalle viste restituite ai client. Ad esempio, un server può inviare dati da un database come HTML, XML o JSON, nessuno dei quali è un tipo di archiviazione all'interno del server.

Manipolare le risorse attraverso una vista

Se il client archivia una rappresentazione della risorsa, inclusi i metadati, dispone di informazioni sufficienti per modificare o eliminare la risorsa sul server.

Messaggi "autodescrittivi".

Ogni messaggio contiene informazioni sufficienti per capire come elaborarlo. Ad esempio, se hai bisogno di informazioni sull'utente, il server ti restituirà un oggetto JSON, dove ci saranno nome, campi indirizzo.

Non dovrebbe esserci una situazione in cui il cliente ha bisogno di sapere che il primo numero nella risposta è l'età e il secondo è la data di nascita.

8.5 Cache

L'approccio REST presuppone che le richieste di dati vengano effettuate tramite il protocollo HTTP. Pertanto, gli oggetti vengono ottenuti chiamando una richiesta GET. Ciò significa che, come tutte le risorse ricevute tramite una richiesta GET, sono soggette a tutte le regole per la memorizzazione nella cache delle risorse HTTP.

Cioè, i dati ricevuti tramite l'API REST vengono memorizzati nella cache allo stesso modo di qualsiasi risorsa statica sui server web. Bellezza :)