.NETでウェブサービスを開発しているなら、ODataを調査対象のフレームワークにするべきだ。特に、よくわからないサードパーティをサポートしなければならない場合だ。ODataはSOAPとATOM (XML)とJSONで表現されるRESTスタイルのメッセージをサポートする。つまり、サービスの利用者は、自分たちにとって最適なフォーマットをリクエストできるのだ。
ODataを始めるなら、Mohamad Halabi氏のUnderstanding OData v3 and WCF Data Services 5.xという記事を読むといいだろう。この記事は、標準的なクイックスタートガイド以上の内容が含まれており、この通信プロトコルそのものの説明をしている。
MicrosoftのODataの実装であるWCF Data Servicesに対する共通の誤解は、MicrosoftのORMであるEntity Frameworkと結びついているということだ。Mohamad氏が明らかにしたのは、Entity Frameworkを使っていないデータソースをウェブサービスで公開する方法だ。静的データを公開するのはシンプルで、List<T>.AsQuerableを呼び出すことでIQueryableプロパティのセットを公開すればいい。MicrosoftはこれをReflection Providerと称している。
より複雑なシナリオの場合は、MSDNのCustom Data Service Providersのページを参照したくなるだろう。このページには実装する必要があるかもしれないさまざまなインターフェースの説明ページへのリンクが含まれている。しかし、残念ながらこれらのインターフェースの多くはあまりドキュメント化されていない。
ODataを使ったサービスを立ち上げる場合、理解する必要がある互換性の問題がある。幸い、Mohamad氏はOData V2とOData V3の違いを説明している。注意を払うべき主要な点はJSONMessageInspectorの登録方法と、JSONとJSON Lightの違い(JSON Lightは多くのメタデータが削除されている)だ。
WCF Data Servicesは第一にCRUDスタイルのサービスを提供することを目的にしている。つまり、作成、読み取り、更新、削除の操作だ。また、ProcessInvoiceメソッドのようなRPCスタイルのサービスも公開できる。これはWebGetとWebInvoke属性で実現できる。残念ながら通常のWCFサービスよりは制限が多い。例えば、“パラメータはプリミティブな型でなければならない”。Service Operationsページでより詳細に説明されている。
ChangeInterceptorとQueryInterceptorはCRUDスタイルのリクエストを書き換えるために使う。この2つは、追加のバリデーションやセキュリティチェックや、操作をブロックして望ましい操作を説明するエラーメッセージを表示するのに利用できる。