Nous utilisons un cadre d'application Web pour créer des applications qui doivent pouvoir interroger une base de données SQL Server et obtenir les résultats sous forme de XML.
Dans le passé, le cadre prévoyait cette capacité. Mais cette capacité est maintenant obsolète.
Nous pensions donc que le framework nous permet d'interroger facilement un service de repos sur http, alors pourquoi ne pas utiliser un point d'extrémité HTTP SQL Server. Cependant, nous lisons ensuite que les points d'extrémité HTTP sont obsolètes, à partir de SQL Server 2008. Pas une plate-forme sur laquelle concevoir une architecture pour l'avenir.
Azure (anciennement SQL Data Services) allait offrir des services similaires, mais ne prend en charge que le protocole TDT, pas http. Donc, pas de repos à trouver dans Azure.
L'alternative suggérée consiste à développer une application personnalisée à l'aide des services de données WCF (anciennement ADO.NET SERVICES SERVICES). Mais cela signifierait une application complémentaire entière pour développer, déployer et entretenir, probablement avec sa propre configuration d'authentification séparée de SQL Server's et son propre référentiel de code source ... Utilisation d'une technologie Nous n'avons aucune expérience avec son propre joli courbe d'apprentissage profonde.
Pouvez-vous suggérer une autre solution pour interroger une base de données SQL Server via REST / HTTP, qui n'est pas obsolète, ce qui rendrait les résultats de XML?
Merci pour une aide.
3 Réponses :
lire ici: Création d'une API Odata pour Stackoverflow, y compris XML et JSON en 30 minutes . Fondamentalement, la route vers l'avant est destinée à être proposée par App calque (EF d'alimentation WCF qui fournit le mappage ODATA). IMHO HTTP HTTP L'accès dans le moteur a été une très mauvaise idée de commencer, personne n'a aimé les httpendpoints de SQL Server 2005 et ils étaient aussi erronés que cela devient. On ne peut pas mapper le modèle d'erreur HTTP, la sécurité, le système de type dans SQL et attendre une interopérabilité en douceur. La mise en place de la couche HTTP dans une application dédiée pousse la responsabilité de gérer l'écosystème HTTP dans un composant spécialisé dans celui (WCF) et la logique de mapper le modèle de repos au composant DB Modèle INA spécialisé dans ce travail (EF). < / p>
OK, merci, si nous décidons de faire la route WCF / ADO.NET, ce didacticiel facilitera la tâche. Toutefois, comme décrit dans la question, nous sommes réticents à le faire car il nécessite d'ajouter une nouvelle boîte à outils (VS et ses composantes / extensions) à notre processus de développement, avec l'ensemble d'artefacts associé pour suivre, déployer et gérer. Pire, étant nouvelle dans cette technologie, nous ne savons même pas ce que les artefacts seront et ceux qui doivent être suivis.
Ok, vous avez donné une bonne justification pour la raison pour laquelle les points d'extrémité HTTP sont partis. En ce qui concerne "personne a aimé", je ne voudrais pas être en désaccord, mais peut-être que les vieillis étaient mal appréciés. Quoi qu'il en soit, ça sonne comme s'il n'y a pas une meilleure option.
On sonne comme si vous pouviez être chargée sur une pile MS, mais si vous n'êtes pas, vous pouvez utiliser RestSQL dans un conteneur Java EE (Tomcat, Weblogic, etc.) sur MySQL ou PostgreSQL. RestSQL dispose d'une API HTTP complète avec JSON ou codage XML. Il propose deux torsions: une vue complete composite et une vue en composite hiérarchique. Le cadre est extensible d'autres bases de données et l'ajout de SQL Server est dans son évolution prise en charge. Découvrez http://restsql.org .
Merci ... Nous garderons certainement cela à l'esprit la prochaine fois que nous examinons la question. Il est vrai que nous sommes assez bien mariés à MS SQL Server pour le moment.
J'en ai besoin, mais .. avec le support Server MS SQL Server: /
Une autre option est quelque chose comme DreamFactory . Ils ont un savon pour se reposer une solution qui vous permet de vous connecter à n'importe quelle base de données ou service. J'ai utilisé leur Solution hébergée gratuite dans le passé pour les projets. Ils ont également une solution open source disponible. La chose cool sur le service est qu'ils utilisent Swagger 3.0 pour créer des définitions de service dans une belle solution frontale afin de pouvoir tester et créer de nouveaux points d'extrémité.
J'ai utilisé les définitions Openapi 3.0 pour se connecter aux services de savon et de repos de 3ème partie. Ils soutiennent également les procédures stockées et les scripts côté serveur dans les environnements SQL Server.
Quoi qu'il en soit, peut-être une autre option pour vous.