2011-08-22 6 views
10

私たちは、Webアプリケーションフレームワークを使用して、SQL Serverデータベースを照会して結果をXMLとして取得する必要があるアプリケーションを構築しています。XMLを取得するためにREST経由でSQL Serverを照会する方法

以前は、フレームワークがその機能を提供していました。しかし、その機能は廃止されました。

フレームワークでは、HTTP経由でRESTサービスを簡単に照会できるので、なぜSQL Server HTTPエンドポイントを使用しないのかと考えていました。ただし、SQL Server 2008の時点では、HTTPエンドポイントは推奨されていません。将来のアーキテクチャを設計するプラットフォームではありません。

Azure(以前のSQL Data Services)も同様のサービスを提供していましたが、httpではなくTDSプロトコルのみをサポートしています。 AzureにはRESTはありません。

代わりに、WCF Data Services(以前のADO.NET Data Services)を使用してカスタムアプリケーションを開発することをお勧めします。しかし、それはおそらく、SQL Serverとは別の独自の認証設定と独自のソースコードリポジトリを使って開発、デプロイ、および保守する追加のアプリケーション全体を意味するだろう。深い学習曲線。

REST/HTTP経由でSQL Serverデータベースにクエリを行う方法はありません。これは非推奨ではなく、結果はXMLとして返されますか?

ありがとうございました。

答えて

5

ここにお読みください:Creating an OData API for StackOverflow including XML and JSON in 30 minutes基本的には、RESTはアプリケーション層(ODataマッピングを提供するWFF EFに対応)によって提供されます。エンジンへのIMHOの直接的なHTTPアクセスは、非常に悪い考えで始まった。誰もSQL Server 2005のHTTPエンドポイントを気に入っていなかった。 HTTPエラーモデル、セキュリティ、タイプシステムをSQLにマッピングすることはできず、スムーズな相互運用性を期待しています。専用のアプリケーションにHTTPレイヤーを公開すると、HTTPエコシステムをそのコンポーネント(WCF)に特化したコンポーネントに処理する責任と、RESTモデルをそのジョブ(EF)に特化したコンポーネントのDBモデルにマッピングするロジックが必要になります。

+0

このチュートリアルでは、WCF/ADO.NETルートへの移行を決定していただきありがとうございます。しかし、問題に説明されているように、開発プロセスに追跡ツール、展開ツール、および管理する関連する一連の成果物を追加して、完全に新しいツールチェーン(VSとそのコンポーネント/拡張機能)を追加する必要があるため、この作業を躊躇します。さらに悪いことに、このテクノロジが初めてのため、アーティファクトがどのようなものであるか、どのアーティファクトを追跡する必要があるのか​​はわかりません。 – LarsH

+0

OK、なぜHTTPエンドポイントが消え去ったのか、良い根拠があります。 「誰も気に入らない」に関しては、私は同意しないだろうが、多分、好き嫌いがあったかもしれない。とにかく、より良い選択肢がないように思えます。 – LarsH

3

MSスタックに組み込まれているようですが、そうでない場合は、MySQLまたはPostgreSQLの上にあるJava EEコンテナ(Tomcat、WebLogicなど)でrestSQLを使用できます。 restSQLには、JSONまたはXMLエンコーディングによる完全なHTTP APIがあります。更新可能なコンポジットビューと階層的コンポジットビューの2つの紆余曲折があります。このフレームワークは他のデータベースに拡張可能であり、SQL Serverの追加はサポートされている進化にあります。 http://restsql.orgをチェックしてください。

+0

ありがとう...私たちは次回にこの問題を見て、このことを念頭に置いています。当面はMS SQL Serverにかなり納得しています。 – LarsH

+0

私はこれを必要としますが、.. MS SQL Serverのサポート:/ –

関連する問題