Il server dovrebbe esporre quei servizi REST, che soddisfano pienamente le tue necessità in front-end per l'applicazione singola pagina. Quando viene sviluppata un'applicazione che funge da client per i dati disponibili tramite i servizi REST, c'è abbastanza spesso comunicazione tra il back-end e il team front-end. Per questo motivo e per le richieste del team di front-end, gli sviluppatori back-end di REST potrebbero decidere di esporre diversi servizi che potrebbero offrire dati o dati abbastanza simili, che potrebbero essere composti da diverse chiamate al servizio REST, esclusivamente per rendere le transazioni costano meno tempo e risorse.
Sia i tuoi servizi web che il tuo front-end hanno regole aziendali, ma il set è praticamente garantito per essere diverso. L'intero middleware REST back-end è lì per fornire un livello di astrazione tra te e il motore del database. Non dovresti davvero preoccuparti se i dati provengono da un file o da un database PostgreSQL, a condizione che tu possa recuperare. È lì per fornire una norma e impostare le regole su quali dati puoi vedere. Oltre a ciò, fornendo un livello di astrazione stai solo esponendo le azioni che vuoi davvero che il pubblico veda.
Dovresti mettere la logica di business che è legata al front-end per l'applicazione front-end e cose come la validazione, login, es. operazioni che devono essere eseguite sul database, nel back-end. Per il front-end molte delle regole aziendali potrebbero consistere in indicatori dell'interfaccia utente, ad esempio se il numero di prodotti è inferiore a 5, visualizzare il prodotto con il titolo rosso e la notifica, che lo stock è basso.
Ma ci saranno casi in cui le regole aziendali di front-end e back-end si sovrappongono. Questo fa sì che le operazioni, che possono essere immediatamente scartate sul front-end, non debbano colpire il servizio back-end.
Immagina uno scenario in cui sei stato loggato in un'applicazione eshop e hai 1500 crediti. Volevi acquistare un prodotto che costava 2000 crediti. È abbastanza ovvio che non è necessario eseguire la transazione purchase nel servizio back-end e una notifica "Fondi insufficienti" può essere inviata direttamente dal front-end, semplicemente confrontando i due valori, del credito corrente e del prezzo del prodotto.
Ma ciò non significa la regola aziendale (che un prodotto è acquistabile solo se hai abbastanza crediti) dovrebbe essere rimosso dal back-end. Offrendo a qualcuno un accesso a un'applicazione, gli stai dando direttamente accesso al codice sorgente. Un programmatore esperto potrebbe hackerare l'applicazione, dargli una quantità infinita di crediti e quindi l'ordine di acquisto sarebbe passato. Ecco perché la regola deve rimanere anche nel back-end, per fornire una convalida lato server che l'azione abbia avuto effettivamente esito positivo.
Per la maggior parte delle persone, la convalida del front-end è sufficiente, ma ci sarà sempre qualcuno che proverà a sfruttarlo e chi deve essere fermato dal server. Il modo in cui un intero sistema è progettato è per una discussione molto lunga e dipende anche dal sistema stesso.
Un po 'sul perché i servizi REST / SOAP sono diventati così popolari.
Alcuni anni fa, quando qualcun altro aveva bisogno di utilizzare i dati del tuo database, dovresti creare un utente specifico, assegnargli il permesso di essere in grado di eseguire query solo su determinate tabelle / viste / procedure, quindi non potevano fare nulla altro. Questo è andato abbastanza bene, finché non l'hai scoperto, il tuo server di database è sotto un carico pesante. Ora cosa? L'utente ha già pubblicato l'applicazione, ha hardcoded la stringa di connessione in esso (che inoltra al computer del database) e quando hai creato uno slave anche se ha cambiato la stringa di connessione, nessuno ha scaricato l'aggiornamento e il server del database continua a masterizzare da tutti carico.
C'è un altro problema con questo, che il client esterno avrebbe effettivamente l'accesso diretto al database stesso, il che, sebbene avesse solo un utente con autorizzazioni limitate, non è davvero di grande sicurezza. Cosa succede se qualcuno decide di DDOS il server che funziona come database principale? Ovviamente, è possibile impostare una certa protezione DDOS su di esso, ma in questo caso si sta mescolando le responsabilità della macchina, fungendo da database e filtro allo stesso tempo.
Introducendo un livello di astrazione, l'API che esponi di solito inoltra a un sistema di bilanciamento, che è un punto di accesso a un numero illimitato di server. Ora il client ha solo accesso al sistema di bilanciamento e tramite la riscrittura IP, la sua richiesta viene reindirizzata a un server effettivo e quindi la risposta viene reindirizzata a lui.
Durante questo processo di richiesta-risposta, potrebbero esserci più livelli, uno potrebbe essere responsabile della prevenzione del DDOS e alcuni potrebbero essere cache. Questo ti consente di scalare molto bene aggiungendo sempre più server quando necessario senza alterare i client che stanno già utilizzando la tua API, il che è sorprendente.