MVC e servizio API RESTful

MVC è un paradigma del mondo Smalltalk interessato a come i sistemi orientati agli oggetti potrebbero avere interfacce utente.

I primi framework web prendevano l'idea generale (separano la logica aziendale, controllando la logica e la logica di visualizzazione) e applicavano il principio al modo in cui strutturavano l'applicazione web. Prima di questo non era raro avere un pasticcio terribile di codice di generazione HTML all'interno di oggetti di dominio, o logica di business all'interno di modelli HTML (si pensi molto presto a PHP)

Il fatto è che l'MVC originale del mondo Smalltalk non è esattamente ciò che MVC è nella maggior parte dei framework web. Un output HTML non è realmente una "visione" nel senso che Smalltalk ha capito che uno schermo dell'interfaccia utente deve essere.

Quindi questa è la prima ragione per non rimanere troppo attaccati a se stai seguendo MVC correttamente. Quasi niente è. Prendilo meno come una divisione rigorosa e più una linea guida di Ehi non sarebbe bello se i nostri modelli HTML non fossero pieni di logica aziendale.

In secondo luogo, MVC è solo un modo per 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 per costruire 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 "vista", va bene. Otterrai comunque benefici separando la tua logica di business (cioè il modello) dai controller che gestiscono una specifica richiesta HTTP, anche se tutto il controller chiama una chiamata di analisi JSON su qualche oggetto e restituisce quei dati.

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

Finché il livello vista pubblica informazioni che possono essere usate da un utente per influenzare i modelli nella tua applicazione, non importa come sia la vista, è comunque una vista, un livello che funge da middleware tra l'utente e il sistema.

Is that how it is should be done?

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

Sto utilizzando la stessa architettura nell'applicazione corrente su cui sto lavorando e funziona molto bene. Insieme a qualche bel framework JS puoi creare dei progetti davvero reattivi.

Or are there any other, better-suited patterns for a API-only service instead of MVC?

Onestamente, non ne ho idea. Ma io penso che se tu usi MVC o meno in una API non è così importante. Usa quello che trovi conveniente. Quando si parla di servizi Web ci sono aspetti molto più importanti da considerare (che non sono direttamente correlati a MVC), ad es. sicurezza, coerenza, disponibilità, ecc.

MVC is pretty straightforward.

Martin Fowler, forse, non è d'accordo con questo :

Different people reading about MVC in different places take different ideas from it and describe these as 'MVC'.

Andare avanti ...

When we create a website, it all come together as 'client sends REST keyword request to server -> the server matches the requested URL to the controller action -> which then calls the model(s) for data gathering/processing, gets the result -> and returns the result back to the client as a HTML page (view)'.

OK, questo è un po 'un groviglio

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

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

Il web, che è quello di cui stai parlando, è una gigantesca applicazione per la gestione dei documenti costruita utilizzando la maggior parte degli stessi vincoli.

Le somiglianze che stai vedendo tra i due sono (prendi la tua scelta) erroneamente attribuite o superficiali.

RESTafarians avere una visione comune di HATEOAS , "ipertesto come motore dello stato dell'applicazione", e che dovrebbe inviare allarmi attraverso la testa - perché una vista può essere un motore di stato ? Se mettiamo in discussione la premessa e cerchiamo ulteriori prove, potremmo notare due cose strane.

Innanzitutto, possiamo togliere completamente il server HTTP dall'equazione caricando l'HTML dal disco. Il browser è perfettamente soddisfatto di questo, scusando alcune piccole variazioni nel comportamento che potrebbero derivare dal cambiamento nell'URL di base. Le viste generalmente 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 una serie di markup di testo che rispondono ai gesti dell'utente, e poi c'è questa cosa "Source View" che mostra il raw HTML 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 Modello oggetto documento , che è stato inizializzato leggendo l'HTML.

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

What if we are talking about a pure RESTful API web service...? Same as before, but there is no 'view'

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

Pensa "DTO" o "Messaggio" e le tue inferenze saranno molto meno probabilità di farti fuori strada.