Comprensione dei servizi web RESTful

1. Sì, la tua comprensione è corretta. Sebbene sia possibile accedere direttamente a alcuni servizi REST, senza passare per il server 2.

2. Ottenere una risposta è questione di millisecondi, specialmente quando i data center sono vicini l'uno all'altro geograficamente (perché in effetti, la velocità della luce è importante). Se stiamo parlando di piccole app Web, il servizio REST e l'app possono essere ospitati sulla stessa macchina, il che potrebbe significare che il tempo perso per lo scambio di dati è inferiore a un millisecondo.

3. Esistono diversi meccanismi di autenticazione. Ad esempio, il Server 2 può utilizzare una chiave API sconosciuta da altri server. Un'altra possibilità è di guardare l'indirizzo IP del client, anche se di solito è meglio avere lo stesso meccanismo di autenticazione per uso interno ed esterno.

4. Sì. I servizi REST vengono utilizzati per applicazioni mobili, applicazioni desktop, app incorporate, ecc.

5. I servizi REST possono essere utilizzati direttamente. Passandoli attraverso un altro server (sarebbe il Server 2 nel tuo diagramma o Server 3) aggiunge un livello di complessità, ma a volte può essere una scelta valida.

Si noti che in molti casi, sono coinvolti più server. Ad esempio, per un sito Web piccolo ma affidabile che non dispone di servizi REST:

• La richiesta di home page di un sito Web può essere gestita da un server di failover (come Nginx) che determina quale dei due server di app deve gestire la richiesta.

• Il server app inizia a gestire la richiesta.

• Questo produce diverse voci di registro che vengono inviate a un server di registro.

• Poiché i dati sono richiesti, i server di database sono sollecitati. Se il primo server di database è inattivo, viene utilizzato quello di failover.

Vedi? Senza alcun servizio REST, sono state utilizzate cinque macchine per generare una risposta (senza contare diversi switch e dispositivi di rete che stavano passando la richiesta e la risposta).

Per fare eco a ciò che MainMan ha detto, ci sono due concetti diversi in gioco qui, REST e microservizi.

Il tuo diagramma è una configurazione di micro-servizi. Puoi farlo con l'architettura RESTful o con qualsiasi altra architettura. Mentre i micro-servizi e il REST vengono spesso usati insieme, non sono la stessa cosa.

REST è un modo di pensare alla comunicazione tra client e server al fine di garantire un accoppiamento lento tra client e server.

È un paradigma diverso dal più tradizionale paradigma di Remote Procedure Call in cui il client invia il comando al server da eseguire. Con RPC il client deve essere consapevole dei comandi che il server comprende, che può cambiare al lavoro sul server.

Con un'architettura REST si limita la comunicazione tra client e server semplicemente ai comandi per trasferire una rappresentazione di un dato. HTTP è un'architettura RESTful e gli unici verbi in HTTP sono GET, PUT, POST, DELETE ecc.

Come esempio della differenza, il tuo servizio riguarda il fotoritocco. In una tradizionale configurazione RPC il client potrebbe inviare al server molti comandi per aggiornare una foto. Il cliente potrebbe dire "Ok, prima sfocare l'immagine, quindi ruotarla, quindi ritagliarla". Il client ha emesso 3 comandi al server.

Il problema è che accoppia il client e il server insieme, in quanto il client deve sapere quali comandi il server capisce. Dì più tardi cambi il comando da "sfocatura" a "sfocatura". Devi aggiornare ogni singolo cliente. O dire che un cliente vuole fare una "sfocatura" ma il server con cui sta parlando ha solo la versione 0.1 del codice server e non capisce "sfocatura". Devi aggiornare il server ogni volta che un cliente vuole fare qualcosa di nuovo.

In REST ciò che accade è, invece, il client dice "Ok server dammi una copia della foto". Il cliente ottiene / scarica una copia della foto e quindi esegue qualsiasi numero di modifiche lato client.

Il client dice "Ok, server store questo nuovo stato della foto".

Tutti i client e i server devono sapere sono i comandi per ottenere e respingere i dati. HTTP è un protocollo REST e se si guardano i verbi HTTP si preoccupano solo dell'ottenere e mettere risorse.

Quindi REST non ha nulla a che fare con l'architettura dei microservizi, ma è invece un modo per pensare a come client e server gestiranno comandi e dati tra loro.