Servizio API MVC e RESTful

MVC è piuttosto semplice. C'è un modello, un controller e una vista. Quando creiamo un sito Web, tutto si riunisce come ' client invia la richiesta della parola chiave REST al server -> il server abbina l'URL richiesto all'azione del controller -> che quindi chiama i modelli per la raccolta / elaborazione dei dati, ottiene il risultato -> e restituisce il risultato al client come pagina HTML (visualizza) '.

E se stiamo parlando di un puro servizio web API RESTful? Quindi il flusso può essere qualcosa come ' client invia la richiesta della parola chiave REST al server -> il server abbina l'URL richiesto all'azione del controller -> che quindi chiama i modelli per la raccolta / elaborazione dei dati, ottiene il risultato -> e ritorna il risultato torna al client in JSON '. Come prima, ma non esiste una "vista" ... o meglio, il JSON generato può essere considerato una "vista". In un certo senso, stiamo utilizzando solo la parte MC di MVC. È così che dovrebbe essere fatto? Oppure ci sono altri schemi più adatti per un servizio solo API invece di MVC?

MVC è un paradigma del mondo Smalltalk interessato al modo in cui i sistemi orientati agli oggetti potrebbero avere interfacce utente.

I primi web framework hanno preso l'idea generale (separare la logica di business, controllare la logica e visualizzare la logica) e applicare il principio al modo in cui hanno strutturato l'applicazione web. Prima di questo non era raro avere Dio un disastro terribile di codice di generazione HTML all'interno di oggetti di dominio o logica di business all'interno di modelli HTML (pensate molto presto a PHP)

Il fatto è che l'MVC originale dal mondo Smalltalk non è proprio quello che MVC è nella maggior parte dei framework web. Un output HTML non è in realtà una "vista", nel senso che Smalltalk ha capito che doveva essere una schermata dell'interfaccia utente.

Quindi questo è il primo motivo per non rimanere troppo indeciso sul fatto che stai seguendo MVC correttamente. Quasi nulla lo è. Prendilo meno come una divisione rigorosa e più una linea guida di Hey non sarebbe bello se i nostri modelli HTML non fossero pieni di logica aziendale.

In secondo luogo MVC è solo un modo di strutturare il codice lato server. Non ha davvero nulla a che fare con REST / HTTP. REST si occupa di come comunicano client e server. Non importa se la rappresentazione che il server invia al client si trova in un modello HTML che ha richiesto molto tempo per essere costruita con un motore di template o un oggetto JSON che era una chiamata nel controller.

Se non pensi che il tuo server abbia bisogno di un livello di "visualizzazione" che vada bene. Otterrai comunque dei vantaggi separando la tua logica di business (cioè il modello) dai controller che gestiscono una specifica richiesta HTTP, anche se tutti i controller chiamano una chiamata di analisi JSON su un oggetto e restituiscono quei dati.

View è un layer responsabile della visualizzazione di informazioni che possono essere interpretate da un utente / client dell'applicazione (non significa che l'utente debba essere una persona reale). JSON è un formato completamente valido per un livello di visualizzazione, i computer lo comprendono.

Finché il livello di visualizzazione pubblica informazioni che possono essere utilizzate da un utente per influire sui modelli dell'applicazione, non importa come appare la vista, è comunque una vista, un livello che funge da middleware tra l'utente e il sistema .

MVC è piuttosto semplice.

Martin Fowler non sarebbe forse d' accordo con questo :

Diverse persone che leggono MVC in luoghi diversi ne prendono idee diverse e le descrivono come "MVC".

Andare avanti...

Quando creiamo un sito Web, tutto si riunisce come 'client invia la richiesta della parola chiave REST al server -> il server abbina l'URL richiesto all'azione del controller -> che quindi chiama i modelli per la raccolta / elaborazione dei dati, ottiene il risultato -> e restituisce il risultato al client come pagina HTML (visualizza) '.

OK, questo è un po 'un groviglio

MVC, qualunque essa sia, è una raccolta di idee per l'implementazione di interfacce utente.

REST è una raccolta di vincoli architetturali per la creazione di applicazioni su larga scala.

Il web, di cui stai parlando qui, è una gigantesca applicazione di gestione dei documenti costruita usando la maggior parte di quegli stessi vincoli.

Le somiglianze che vedi tra i due sono (fai la tua scelta) erroneamente attribuite o superficiali.

I RESTafariani hanno una comprensione comune di HATEOAS , "ipertesto come motore dello stato dell'applicazione", e questo dovrebbe far scattare degli allarmi nella tua testa - perché una vista dovrebbe essere un motore di stato ? Se mettiamo in dubbio la premessa e cerchiamo ulteriori prove, potremmo anche notare due cose strane.

Innanzitutto, possiamo rimuovere completamente il server HTTP dall'equazione caricando l'HTML dal disco. Il browser è perfettamente soddisfatto di ciò, giustificando alcune lievi variazioni nel comportamento che possono derivare dalla modifica dell'URL di base. Le viste in genere non continuano a funzionare quando sono state completamente disconnesse dal modello e dal controller in quel modo.

In secondo luogo, se osserviamo attentamente un browser moderno, noteremo che ci sono più viste dell'HTML. Le viste multiple di una vista sembrano un'idea davvero strana, ma sicuramente c'è la presentazione principale, con un sacco di markup di testo che risponde ai gesti degli utenti, e poi c'è questa cosa "Vista sorgente" che mostra l'HTML grezzo e risponde anche a gesti dell'utente. Sono le tartarughe fino in fondo!

La risposta all'enigma, ovviamente, è che l'HTML non è la vista. La raccolta di widget nel browser è la vista e sono in comunicazione con il Document Object Model , che è stato inizializzato leggendo l'HTML.

In altre parole, l'HTML è una rappresentazione dello stato, proprio come promesso da Roy T. Fielding .

E se stiamo parlando di un puro servizio web API RESTful ...? Come prima, ma non c'è "vista"

Più correttamente, come prima: non c'è vista. JSON, proprio come l'HTML, è una rappresentazione di stato, adatta per attraversare i confini del processo.

Pensa "DTO" o "Messaggio" e le tue inferenze avranno molte meno probabilità di portarti fuori strada.

È così che dovrebbe essere fatto?

Passare JSON come vista o usarlo come modello di vista per costruire la vista non viola il modello.

Sto usando la stessa architettura nell'applicazione corrente su cui sto lavorando e funziona molto bene. Insieme ad alcuni simpatici framework JS è possibile creare progetti davvero reattivi.

Oppure ci sono altri schemi più adatti per un servizio solo API invece di MVC?

Onestamente, non ne ho idea. Ma penso che l'utilizzo di MVC o meno in un'API non sia così importante. Usa quello che ritieni conveniente. Quando si parla di servizi Web, ci sono molti aspetti più importanti da considerare (che non sono direttamente correlati a MVC), ad esempio sicurezza, coerenza, disponibilità, ecc.