2011-08-22 6 views
10

Użyliśmy ramy aplikacji internetowych do tworzenia aplikacji, które muszą być w stanie zapytać o bazę danych SQL Server i uzyskać wyniki w postaci XML.w jaki sposób zapytać SQL Server przez REST, aby uzyskać XML

W przeszłości ramy przewidywały taką możliwość. Ale ta zdolność jest teraz przestarzała.

Tak więc pomyśleliśmy, że framework pozwala nam łatwo zapytać usługę REST przez HTTP, więc dlaczego nie używać punktu końcowego HTTP serwera SQL. Jednak później przeczytaliśmy, że HTTP Endpoints są przestarzałe, podobnie jak SQL Server 2008. Nie jest to platforma, na której można zaprojektować architekturę na przyszłość.

Azure (dawniej SQL Data Services) zamierzał oferować podobne usługi, ale teraz obsługuje tylko protokół TDS, a nie http. Dlatego nie można znaleźć usługi REST na platformie Azure.

Sugerowana alternatywa polega na opracowaniu niestandardowej aplikacji przy użyciu usług danych WCF (dawniej ADO.NET Data Services). Ale to oznaczałoby, że cała dodatkowa aplikacja będzie się rozwijać, wdrażać i utrzymywać, prawdopodobnie z własną konfiguracją uwierzytelniania oddzieloną od SQL Servera i własnym repozytorium kodu źródłowego ... przy użyciu technologii, z którą nie mamy żadnego doświadczenia, a więc z własną ładną głęboka krzywa uczenia się.

Czy można zaproponować inny sposób kwerendy do bazy danych SQL Server za pośrednictwem REST/HTTP, który nie jest przestarzały, a które zwróci wyniki jako XML?

Dzięki za pomoc.

Odpowiedz

5

Przeczytaj tutaj: Creating an OData API for StackOverflow including XML and JSON in 30 minutes. Zasadniczo, droga do przodu jest dla REST oferowana przez warstwę aplikacji (WCF zasilający EF, który zapewnia mapowanie OData). IMHO prosty dostęp HTTP do silnika był bardzo złym pomysłem na początek, nikt nie polubił punktów HTTPEndpoints SQL Server 2005 i były one tak błędne, jak to tylko możliwe. Nie można odwzorować modelu błędu HTTP, bezpieczeństwa, systemu typów na SQL i oczekiwać płynnej współdziałania. Umieszczenie warstwy HTTP w dedykowanej aplikacji powoduje przeniesienie odpowiedzialności za obsługę ekosystemu HTTP na wyspecjalizowany komponent (WCF) oraz logikę mapowania modelu REST na model DB w komponencie specjalizującym się w tym zadaniu (EF).

+0

OK, dziękuję, jeśli zdecydujemy się na trasę WCF/ADO.NET, ten samouczek ułatwi. Jednak, jak opisano w pytaniu, nie chcemy tego zrobić, ponieważ wymaga on dodania całego nowego toolchain (VS i jego komponentów/rozszerzeń) do naszego procesu rozwoju, z powiązanym zestawem artefaktów do śledzenia, wdrażania i zarządzania. Co gorsza, będąc nowicjuszem w tej technologii, nie wiemy nawet, jakie artefakty będą i które należy śledzić. – LarsH

+0

OK, podałeś dobre uzasadnienie, dlaczego punkty końcowe HTTP zniknęły. Jeśli chodzi o "nikogo nie lubię", nie zgadzam się, ale być może nie podobają mu się podobne. W każdym razie wygląda na to, że nie ma lepszej opcji. – LarsH

3

Wygląda na to, że możesz zostać przywiązany do stosu MS, ale jeśli nie, możesz użyć restSQL w kontenerze Java EE (Tomcat, WebLogic itp.) Na MySQL lub PostgreSQL. restSQL ma pełne API HTTP z kodowaniem JSON lub XML. Oferuje dwa skręty: aktualizowane widoki złożone i hierarchiczne widoki złożone. Ramy są rozszerzalne do innych baz danych i dodatek SQL Server jest w jego wspieranej ewolucji. Sprawdź http://restsql.org.

+0

Dzięki ... na pewno będziemy o tym pamiętać następnym razem, gdy spojrzymy na problem. To prawda, że ​​na razie jesteśmy dość dobrze przywiązani do MS SQL Server. – LarsH

+0

Potrzebuję tego, ale .. z obsługą MS SQL Server: / –

Powiązane problemy