In un server - > scenario client, non sarebbe più semplice e veloce concedere a un utente pubblico l'accesso a una Stored Procedure piuttosto che l'utilizzo di servizi Web (XML, REST, SOAP, ecc.) e altre soluzioni interoperabili?
In questo modo puoi collegarti direttamente a un database e ottenere contenuti pertinenti e fare ciò che vuoi con esso nello stesso modo in tutte le lingue e i sistemi?
Penso che la chiave sia giusta nella tua domanda:
In a server -> client scenario, wouldn't it be simpler and faster to grant a public user access to a Stored Procedure rather than using web services (XML, REST, SOAP, etc) and other interoperable solutions?
Come qualsiasi forma di fornitore di servizi, ci sono dei compromessi che fai, uno di questi spesso negozia la flessibilità dell'accesso diretto a qualcosa che i tipi di utenti esperti apprezzano, con la facilità d'uso di una soluzione più interoperabile.
Quindi iniziamo dicendo che ci sono problemi di sicurezza . Potrebbero non essere tanto il server SQL stesso, ma piuttosto i rischi inerenti ogni volta che esponi un computer a Internet. Il vantaggio di farlo con il tuo server web invece del tuo server di database è uno dei fattori di mitigazione del rischio.
Il treno di pensiero generalmente va così: se il tuo sistema operativo ha rilevato un difetto di sicurezza e il tuo server di database è esposto a Internet, qualcuno potrebbe sfruttare questa vulnerabilità per ottenere l'amministratore su quella macchina esposta - voila Tutti i tuoi dati appartengono a loro . Quindi, di solito, i server Web che non dispongono di dati e che non hanno quasi nessuna autorizzazione sul DB sono esposti a Internet. Se qualcuno ottiene la radice su questi, dovrebbero idealmente avere solo le autorizzazioni per fare ciò che il sito può fare in modo che l'aggressore non abbia guadagnato nulla.
I problemi di sicurezza sono (probabilmente) il motivo numero 1 per cui le persone non lo fanno nella pratica, ma assumeremo un mondo ideale in cui un server di database esposto non ha problemi di sicurezza per un momento.
In questo mondo ideale, cosa succede quando hai alcuni dati che vuoi vengano esposti e crei ed esporti la stored procedure? A chi hai appena esposto questi dati? L'intera internet? Sort of. In realtà hai esposto questi dati a tutti con le competenze, gli strumenti e il tempo necessari per creare una connessione e accedere alla stored procedure.
Ora chiediamo una versione leggermente diversa della domanda precedente: che cosa accade quando hai alcuni dati che vuoi mostrare - a chi vuoi essere esposto? Se il tuo obiettivo principale è esporre quei dati su Internet in generale, ti consigliamo di creare una pagina web che mostri tali dati. A questo punto, hai già creato la soluzione interoperabile, quindi ora quale valore ha l'accesso alla stored procedure diretta? Lo stesso valore di prima, suppongo, eccetto che gli utenti esperti probabilmente userebbero semplicemente l'interfaccia interoperabile al posto di quella del server SQL perché è più semplice.
Prendiamo un altro approccio al pensiero di cui sopra - Che cosa succede se il tuo obiettivo principale che vuoi esporre i dati è di sviluppatori di terze parti? Grandi, probabilmente hanno le competenze, il tempo e gli strumenti per accedere la procedura memorizzata direttamente! Ma aspetta un attimo, se hai fissato un set di consumatori del tuo set di dati, hai davvero bisogno di esporre il server a l'intero internet ? Non proprio, semplificherà le cose da una prospettiva di sicurezza e auditing molto se crei tunnel sicuri per i tuoi utenti di terze parti che li mettono in una intranet efficace con il tuo DB - una rete intranet è esattamente come le persone normalmente accedono ai DB in ogni caso quindi ora tu tornare allo scenario tipico.
Quindi, spero di aver illustrato alcuni esperimenti di pensiero logico e un po 'di guidare il testimone, possiamo essere d'accordo sul fatto che i tempi in cui tale scenario fornisce effettivamente valore sono piuttosto limitati. Suppongo che potresti farlo, e potrebbe anche esserci un caso limite che colpisci dove effettivamente ha senso. Tuttavia, non appena fai questo salto logico, devi anche riconoscere ci sono rischi per la sicurezza . In conclusione: perché preoccuparsi?
Lo svantaggio è che il tuo cliente ora sa che stai fornendo dati da un database tramite stored procedure e deve collegarsi direttamente a quello per ottenere i dati. Se volessi cambiare ad es. una soluzione NoSQL, o la chiamata proxy su un'altra parte, o le richieste di bilanciamento del carico, ecc. ecc. ecc., è molto più difficile se non si ha un livello tra i dati e il client.
In sostanza, se hai;
Client <====> Interoperability Layer <====> Data
Quindi il livello potrebbe fare qualsiasi cosa ... o non molto. Ma ora sei libero di cambiare ciò che fa in qualsiasi momento, purché l'interfaccia con il client non cambi.
Oltre al motivo di sicurezza. 1) Ognuno sa come accedere ai dati attraverso la stored procedure? 2) Ogni volta avrai strumenti di interrogazione nel loro PC \ Laptop?
Se è un requisito del cliente, dobbiamo soddisfarlo. Inoltre, abbiamo bisogno di spiegare i problemi di sicurezza quando il server di database è esposto a Internet.
Leggi altre domande sui tag programming-languages sql java web-services interoperability