2011-08-22 12 views
10

Abbiamo utilizzato un framework di applicazioni Web per creare app che devono essere in grado di eseguire query su un database SQL Server e ottenere i risultati in formato XML.come interrogare SQL Server tramite REST per ottenere XML

In passato, il framework forniva tale funzionalità. Ma questa capacità è ora deprecata.

Quindi stavamo pensando, il framework ci consente di interrogare facilmente un servizio REST su HTTP, quindi perché non utilizzare un Endpoint HTTP di SQL Server. Tuttavia, leggiamo che gli endpoint HTTP sono deprecati, come di SQL Server 2008. Non una piattaforma su cui progettare un'architettura per il futuro.

Azure (in precedenza SQL Data Services) offriva servizi simili, ma ora supporta solo il protocollo TDS, non http. Quindi nessun REST può essere trovato in Azure.

L'alternativa suggerita è lo sviluppo di un'app personalizzata tramite WCF Data Services (in precedenza ADO.NET Data Services). Ma ciò significherebbe un'intera app aggiuntiva per lo sviluppo, la distribuzione e la manutenzione, presumibilmente con la propria configurazione di autenticazione separata da SQL Server e il proprio repository del codice sorgente ... utilizzando una tecnologia di cui non abbiamo esperienza, quindi con il suo bel curva di apprendimento profonda.

Puoi suggerire un altro modo per interrogare un database SQL Server tramite REST/HTTP, che non è deprecato e che restituirebbe i risultati come XML?

Grazie per qualsiasi aiuto.

risposta

5

Leggi qui: Creating an OData API for StackOverflow including XML and JSON in 30 minutes. Fondamentalmente, la strada da percorrere è che REST sia offerto dal livello dell'app (EF che alimenta WCF che fornisce la mappatura OData). L'accesso HTTP IMHO dritto al motore è stata una pessima idea, nessuno è piaciuto a HTTPEndpoints di SQL Server 2005 e sono stati fuorviati. Non è possibile mappare il modello di errore HTTP, la sicurezza, digitare il sistema in SQL e aspettarsi un'interoperabilità fluida. Avere il livello HTTP in diretta in un'app dedicata spinge la responsabilità di gestire l'ecosistema HTTP in un componente specializzato in quello (WCF) e la logica di mappare il modello REST al modello DB in un componente specializzato in quel lavoro (EF).

+0

OK, grazie, se decidiamo di seguire il percorso WCF/ADO.NET, questo tutorial renderà più semplice. Tuttavia, come descritto nella domanda, siamo riluttanti a farlo perché richiede l'aggiunta di un'intera nuova toolchain (VS e i suoi componenti/estensioni) al nostro processo di sviluppo, con il set associato di risorse da monitorare, distribuire e gestire. Peggio ancora, essendo nuovi a questa tecnologia, non sappiamo nemmeno quali saranno gli artefatti e quali devono essere rintracciati. – LarsH

+0

OK, hai fornito una buona spiegazione del motivo per cui gli endpoint HTTP sono andati via. Per quanto riguarda "nessuno è piaciuto", non sarei d'accordo, ma forse i parenti erano mal consigliati. Ad ogni modo, sembra che non ci sia un'opzione migliore. – LarsH

3

Sembra che tu possa essere associato a uno stack MS, ma se non lo sei, puoi usare restSQL in un contenitore Java EE (Tomcat, WebLogic, ecc.) Su MySQL o PostgreSQL. restSQL ha un'API HTTP completa con codifica JSON o XML. Offre due colpi di scena: viste composite aggiornabili e viste composte gerarchiche. Il framework è estensibile ad altri database e l'aggiunta di SQL Server è nella sua evoluzione supportata. Controlla http://restsql.org.

+0

Grazie ... lo terremo sicuramente presente la prossima volta che esamineremo il problema. È vero che per il momento siamo abbastanza ben sposati con MS SQL Server. – LarsH

+0

Ho bisogno di questo, ma .. con supporto MS SQL Server: / –

Problemi correlati