REST MVC Confusion for An Enterprise Appplication Architecture [chiuso]

Supponiamo che se stai parlando di un progetto MVC, stai parlando di un'implementazione lato server. Il controller (UI) accetterà una richiesta, invocherà la logica aziendale (modello), renderizzerà una vista e la restituirà al client.

Supponiamo che se stai parlando di una versione REST di un sito web, ti stai spostando verso un'implementazione parzialmente client-side. Il tuo cliente, presumibilmente nel browser, accetterà una richiesta, determinerà quale interfaccia REST chiamare (modello) e renderizzare una vista direttamente sul client (browser).

Ci sono molti framework sul lato client per realizzare questo, AngularJS ReactJS, EmberJS, per nominarne alcuni JavaScript. Quando si desidera aggiornare / rielaborare un sito Web in questo modo, è possibile inserire la logica aziendale esistente negli endpoint REST e chiamarli dal nuovo framework client scelto. Ci saranno senza dubbio suggerimenti dettagliati su come mantenere lo stato dei clienti nel framework scelto.

Le sfide che affronterete implicheranno l'abbattimento della logica aziendale in risposte che possono essere facilmente serializzate e sensate. Ad esempio, dove hai utilizzato per recuperare tutti i dati per tutti i clienti e visualizzato un riepilogo di tutti i clienti o i dettagli per un cliente specifico, ora hai bisogno di due endpoint REST separati, uno per un riepilogo di tutti i clienti e uno per il dettaglio di un cliente specifico. Sebbene tale cambiamento sia generalmente un miglioramento del sistema, non determina necessariamente l'utilizzo o meno di un framework lato server o di un framework lato client.

I framework lato client potrebbero dover essere eseguiti su qualsiasi browser o telefono cellulare che arriva al tuo sito e potrebbero non essere adatti a siti Web complessi. I dati sensibili esposti al mondo dagli endpoint REST potrebbero non essere una buona idea. D'altra parte, i framework lato client possono abilitare un sito web a cose davvero interessanti e possono migliorare la reattività se fatto bene, ma lo sforzo complessivo richiesto quando si aggiunge il codice lato client probabilmente equivale al quadrato del prodotto della complessità del sito Web e il numero di piattaforme client diverse che devi supportare, quindi fai attenzione.

Innanzitutto cos'è un'API RESTful

Per chiarire alcune cose API RESTful (ovvero un servizio) sono un mezzo per comunicare le tue applicazioni. Crea un servizio e poi molti clienti che possono farne richiesta.

Che cos'è un cliente? Queste sono molte cose come l'interfaccia utente web front-end, un motore di reporting, il sistema di fatturazione, la ricerca e così via.

Quindi nel tuo esempio creerai un servizio API RESTfull per il client front-end su cui effettuare richieste. Un servizio RESTful invierà i dati di solito come json. Il client quindi elabora ulteriormente l'elaborazione della risposta e la visualizza come appropriato.

Una cosa da notare qui è sì il servizio è senza stato ma il client non lo è. Il tuo cliente può avere sessioni e cookie. Dovrà passare tali informazioni nella richiesta al servizio per l'elaborazione utilizzando la risposta per aggiornare lo stato.

Quindi, ad esempio, un cliente potrebbe effettuare una chiamata a percorsi come:

/user/create //A POST request with all the information needed to create a user
/user/{:id}/profile //A GET request to find get the information needed for a 
                    //user profile with whatever the id is.

Quindi un'API RESTful è un'architettura di alto livello per la comunicazione delle applicazioni.

Dove si trova MVC in questo?

Un passo indietro in un'applicazione è dove MVC (così come MVP, MVVM, ecc.) viene utilizzato per creare separazioni di interesse. Questi schemi aiutano a non ottenere parti e parti disparate ovunque e una maggiore logica nelle visualizzazioni, quindi html. Lo vedresti implementato all'interno del client front-end perché al servizio non interessa le viste solo i dati (la vista è la V in MVC).

Per decomprimere MVC:

(M) odel - è un contenitore più o meno per contenere i dati. Potrebbe essere un modello user o un modello più grande come profile che ha un user , cart , payment , ecc. Ha una struttura e alcuni elementi noti e probabilmente alcuni metodi per la manipolazione dei dati.

(V) iew - è il modo di visualizzare le informazioni all'utente (browser con HTML). Questa potrebbe essere una pagina php che riprende il modello sopra riportato e lo analizza nelle varie sezioni di una pagina. Una cosa su cui è abbastanza d'accordo è che questo non dovrebbe contenere molta logica. Si tratta principalmente della presentazione dei dati raccolti.

(C) ontroller - orchestra l'applicazione. In base a dove una richiesta del browser colpisce, sa dove ottenere le informazioni per riempire il modello in questo caso una richiesta all'API del servizio RESTful. Il modello viene quindi inserito in una vista e quindi inviato nuovamente al browser degli utenti.

Sommario

La bellezza della creazione di un servizio RESTful è che può essere in qualsiasi cosa e quindi il client può trovarsi in qualsiasi cosa purché sia possibile effettuare chiamate su http / https. Il MVC viene utilizzato in un client che gestisce il modo in cui gli utenti interagiscono con tale API.

Implementazioni

Ora come per un'implementazione in PHP, controlla tutti i framework Laravel, codeignitor, symfony e yii tutti mi vengono in mente (ho usato 0%) e vediamo se sono adatti ai tuoi bisogni.

Si noti che è possibile far crescere il servizio a casa e quindi scegliere un framework per qualsiasi client di solito costruisco il mio servizio in PHP o Java (PHP ha slimeframework e Java JAX-RS) e poi scegliere l'hottness che voglio usare per quello giorno nel client (Angular, React, GO o più PHP, si spera non sia Java).

Bene che tu abbia deciso di passare a MVC, il tempo si è dimostrato facile da mantenere. Il mio suggerimento è di andare con un semplice framework come codeigniter.

Durante la progettazione, assicurati di spostare l'intera logica su un livello di servizi e utilizza i controller solo per eseguire da sola la parte di controllo. Quindi il tuo controller web recupererà i dati dalla richiesta e li metterà nella tua entità, che passerai al servizio. Il servizio avrà logica aziendale, database ecc. E risponderà usando l'entità. Allo stesso modo, quando parli dell'API REST, anche questo diventa un controller che prende i dati dal post o ottiene i parametri, lo inserisce nell'entità e passa allo stesso servizio che hai scritto in precedenza. Quindi stai riutilizzando i servizi.

Arrivando al numero della sessione, non salvare il più possibile nulla nella sessione.

Se hai bisogno di usare qualche tecnica di caching disponibile con il framework di tua scelta o qualcosa come memcache, redis ecc.

spero che questo aiuti.

Dove l'API REST e l'interfaccia utente web hanno la stessa funzionalità e l'unica differenza è il formato consegnato, utilizzare il formato richiesto ( .json o .xml suffisso sul percorso richiesto anziché .html ) per decidere quale vista utilizzare per formattare gli oggetti prodotti dall'azione del controller. Funzionerà meglio dove l'interfaccia utente web è stata progettata come un'applicazione RESTful in primo luogo. Laddove vi siano differenze significative nel flusso e le richieste fatte dall'API REST rispetto all'interfaccia utente Web, sarebbe meglio separare le due all'interno della stessa applicazione Web in modo che possano condividere elementi di logica aziendale e modello di dati comuni. L'applicazione potrebbe avere un web e uno spazio dei nomi api per controllori e viste, con percorsi che iniziano con /web/ o /api/ a seconda di quali controller dello spazio dei nomi avrebbero gestito tale richiesta.

Per quanto riguarda lo stato della sessione, anche l'interfaccia utente web dovrebbe tentare di memorizzare il minore stato possibile nella sessione con l'obiettivo di memorizzare tutti gli stati necessari nel database o in un altro archivio di persistenza o come parte del percorso (Ad esempio, le pagine relative a un determinato utente hanno l'ID utente nel percorso). La sessione normalmente contiene solo cose come un token di autenticazione (per verificare che l'utente si sia autenticato correttamente) o il nome utente o l'ID che hanno autenticato come. Questo potrebbe essere necessario tanto dall'API REST se è stato progettato con una richiesta di autenticazione che ha controllato le credenziali e impostato il token di autenticazione proprio come avrebbe fatto l'azione di accesso all'interfaccia utente web.

Ho poca esperienza da cui cercherò di aiutarti. Una volta che l'app viene utilizzata per utilizzare MVC, è necessario applicare la modalità di interazione REST. Modo RESTful significherà: 1. ci sono risorse che stai cercando di esporre, e non servizi, e i client ottengono l'accesso a loro con URL appropriati. 2. utilizzare i verbi HTTP Leggi qui: link

Inoltre, per mantenere lo stato nel meccanismo RESTful, devi passare avanti e indietro i token di autenticazione. Ad esempio, puoi fare il login del cliente prima di accedere al tuo server. Quindi, nella risposta di accesso, restituire un token di autenticazione. E lascia che il client lo usi nell'intestazione della richiesta per ulteriori chiamate sicure, che puoi sempre validare usando, ad esempio in Jersey, SecurityContext.

Ora, per mantenere lo stato, puoi renderlo lato client (cookie, browser locale ecc.) o lato server (in modo da poter validare il contesto su ogni richiesta e decidere di rinnovare o terminare lo stato come da implementazione). Poiché gli URL non conoscono nulla sullo stato, possono solo trasportare il sessiontoken nelle intestazioni delle richieste se lo si implementa e la posizione del client di risorse nel tentativo di cercare.

Stai facendo domande su un framework in modo frammentario, potrebbe essere meglio rivedere un framework di applicazioni web MVC che fornisca indicazioni sugli argomenti che stai chiedendo. (REST, stato della sessione, separazione delle preoccupazioni) Se hai intenzione di continuare a utilizzare PHP, perché non pensi di utilizzare Ruby On Rails? È un framework MVC molto popolare che si integra anche con i progetti RESTful. Questo sito, link , fornisce un punto di partenza.

Segnala questo link i migliori-disponibili-php-restful-micro-framework e trova un framework che soddisfi le tue esigenze per portare la tua idea / implementazione dall'applicativo basato su supporto basato su MVC tradizionale. Il sito ha elencato i framework per php che fornisce funzionalità sofisticate per creare rapidamente applicazioni basate sui servizi.

Suggerirei di dare un'occhiata a framework laravel che è un prodotto maturo ed elegante, potrebbe aiutarti a soddisfare il requisito . .