Come gestire i modelli tra client Web (DMZ) e web API?

Question

Come gestire i modelli tra client Web (DMZ) e web API?

Naviga le tue risposte

#1 da (2 voti)

0

Ho questo progetto di API Web che gestisce tutti gli accessi al database tramite il framework di entità.

Ho un altro client web che risiede in DMZ per chiamare tali API (tramite ajax o c #) nel progetto dell'API web.

Quando eseguo chiamate API tramite c #, i modelli che passano tra client Web e API Web sono gli stessi.

Per l'API Web, il modello viene generato dal framework di entità (prima il database).

Per il web client, creo una classe del modello.

Ora quando cambio \ aggiorna la tabella nel database, posso facilmente aggiornare il modello nella web API tramite l'entity framework ma devo aggiornare manualmente la classe del modello nel client web.

È facile quando mantengo solo alcuni modelli, non quando ho molti modelli.

Dovrei separarli solo per motivi di separazione o posso semplicemente chiedere al web client di fare riferimento alle API web e usare solo quei modelli generati dal framework di entità?

Ci sono problemi di sicurezza se chiedo al web client di fare riferimento al progetto dell'API web?

Come devo gestire i modelli tra client Web e API Web in questa situazione?

security industry-standard model asp.net-mvc-web-api

posta Pop 11.12.2018 - 05:11

fonte

1 risposta

Leggi altre domande sui tag security industry-standard model asp.net-mvc-web-api

Convenzione Java - Implementazione di due funzioni simili per due oggetti diversi Classe privata nel repository ORM?

score 2 · Answer 1

Sì, dovresti dividerli.

Perché?

Sicurezza e privacy
Compatibilità all'indietro

Sicurezza e privacy

Immagina di avere un utente e che l'utente abbia una password:

desideri restituire tale password quando restituisci l'utente?
Che ne dici di quando restituisci un elenco di utenti?
Dovresti restituire la password a un Utente che non è l'Utente richiesto?

La risposta è NO a tutte quelle domande.

Ora hai una mancata corrispondenza:

L'utente che è archiviato nel database deve avere una password.
L'utente che viene ricevuto al momento della registrazione, accesso o modifica della password deve avere una password.
L'utente che viene ricevuto in qualsiasi altro momento Non deve avere una password.
L'utente che viene restituito Non deve avere una password.

Compatibilità con le versioni precedenti

Immagina uno scenario in cui hai un'applicazione che altre persone installano sulle loro macchine e ti pagano per far funzionare quell'applicazione. A loro non piacerà essere costretti ad aggiornare solo perché hai rilasciato una funzione, in particolare se vuoi più soldi per questo.

Ma i tuoi nuovi clienti vogliono questa funzionalità e aggiorneranno. Come si soddisfano le esigenze di entrambi i gruppi?

La risposta è alla versione dei modelli usati dalla tua API (ad esempio v1, v2, v3, ...). Ciò consente ad alcuni client di utilizzare i modelli v1 mentre altri utilizzano i modelli v2. Sarà compito dell'API mappare entrambi i gruppi di modelli sui modelli utilizzati nel livello di persistenza.