2011-08-22 21 views
10

Hemos estado utilizando un marco de aplicación web para crear aplicaciones que necesitan para poder consultar una base de datos SQL Server y obtener los resultados como XML.Cómo realizar consultas SQL Server a través de REST para obtener XML

En el pasado, el marco proporcionaba esa capacidad. Pero esa capacidad ahora está en desuso.

Por lo que estaban pensando, el marco permite para consultar fácilmente un servicio REST a través de HTTP, ¿por qué no utilizar un HTTP SQL Server de punto final. Sin embargo, leemos que los puntos finales HTTP están en desuso, a partir de SQL Server 2008. No es una plataforma en la que diseñar una arquitectura para el futuro.

Azure (anteriormente SQL Data Services) iba a ofrecer servicios similares, pero ahora sólo es compatible con el protocolo TDS, no http. Así que no se puede encontrar REST en Azure.

La alternativa propuesta es desarrollar una aplicación personalizada utilizando WCF Data Services (anteriormente ADO.NET Data Services). Pero eso significaría una aplicación adicional completa para desarrollar, implementar y mantener, presumiblemente con su propia configuración de autenticación separada de la de SQL Server, y su propio repositorio de código fuente ... utilizando una tecnología con la que no tenemos experiencia, por lo tanto, con su propia bonita curva de aprendizaje profundo

Puede sugerir cualquier otra forma de consultar una base de datos de SQL Server a través de REST/HTTP, que no es obsoleto, y que podría devolver resultados como XML?

Gracias por cualquier ayuda.

Respuesta

5

leer aquí: Creating an OData API for StackOverflow including XML and JSON in 30 minutes. Básicamente, el camino a seguir es que REST sea ofrecido por la capa de aplicación (WCF powering EF que proporciona el mapeo OData). El acceso HTTP directo en mi humilde opinión al motor era una muy mala idea para empezar, a nadie le gustaban los HTTPEndpoints de SQL Server 2005 y estaban lo más equivocados posible. No se puede mapear el modelo de error HTTP, la seguridad, el tipo de sistema en SQL y se espera una interoperabilidad fluida. Tener la capa HTTP en vivo en una aplicación dedicada lleva a la responsabilidad de manejar el ecosistema HTTP en un componente especializado en ese (WCF) y la lógica de mapear el modelo REST al modelo DB en un componente especializado en ese trabajo (EF).

+0

Bien, gracias, si decidimos ir a la ruta WCF/ADO.NET, este tutorial lo hará más fácil. Sin embargo, como se describe en la pregunta, somos reacios a hacerlo porque requiere agregar una cadena de herramientas completamente nueva (VS y sus componentes/extensiones) a nuestro proceso de desarrollo, con el conjunto de artefactos asociados para rastrear, implementar y administrar. Peor aún, siendo nuevo en esta tecnología, ni siquiera sabemos cuáles serán los artefactos y cuáles necesitan ser rastreados. – LarsH

+0

Bien, has dado una buena explicación de por qué los puntos finales HTTP se han ido. En cuanto a "nadie le gustó", estaría en desacuerdo, pero tal vez los simpatizantes fueron desacertados. De todos modos, parece que no hay una mejor opción. – LarsH

3

Parece que puede estar casado con una pila de MS, pero si no lo está, puede usar restSQL en un contenedor Java EE (Tomcat, WebLogic, etc.) encima de MySQL o PostgreSQL. restSQL tiene una API HTTP completa con codificación JSON o XML. Ofrece dos giros: vistas compuestas actualizables y vistas compuestas jerárquicas. El marco es extensible a otras bases de datos y la adición de SQL Server está en su evolución compatible. Consulte http://restsql.org.

+0

Gracias ... definitivamente vamos a tener esto en cuenta la próxima vez que veamos el problema. Es cierto que por el momento estamos bastante ligados a MS SQL Server. – LarsH

+0

Necesito esto, pero ... con el soporte de MS SQL Server: / –

Cuestiones relacionadas