OData概述

Open Data Protocol (OData)是微軟支持且定義出來的網頁開放式資料協定，此協定支援ATOM Publishing Protocol(AtomPub，XML)及JSON格式，在最新OData 4.0版本使用REST原則，近期被OASIS委員會所採納。OData支援資料模型的描述及根據資料模型的資料進行查詢與更新功能，協定的規則來自於REST規範，並透過既有的HTTP加上標準的CRUD方式所組成。而OData的設計原則依循以下幾個理念：

1.傾向機器能儲存各種資料來源
2.服務能支援拓展性的功能
3.以REST設計原則為導向
4.容易地建立兼容的服務
5.保持簡單

為瞭解OData的應用領域，圖一顯示OData定義抽象的資料模型和協定讓任一客戶端能夠公開的存取任一種資料來源。OData允許不同的客戶端能存取不同的資料來源。

• Custom Applications：
  
  Facebook、Netflix and eBay 這些企業級應用對於開放式資料都可以透過OData來存取，而不是使用自己的機制去存取這些資料。為了更容易去達成此目的，.Net Framework和Java Applications可以利用OData libraries作為資料來源。



• Cloud Storage：
  
  Microsoft’s Windows Azures內建OData資料表的存取協定，另外OData也在SQL Azure中支援存取關聯式的資料。其它雲端平台如Amazon web services也有機會利用OData libraries存取資料。



• Content Management Software：
  
  SharePoint 2010與Webnodes支援內建的OData存取公開資料。



• Windows Azure Marketplace DataMarket：
  
  以Windows Azure Marketplace DataMarket為基礎的服務用來搜尋、購買和存取商業資料皆能經由OData的方式讓應用程式存取這些資料集。



• Web Browsers：
  
  JavaScript Code是目前任何受歡迎的網頁瀏覽器中都能執行，如Internet Explorer或是Firefox，這些瀏覽器可以對OData的資料來源進行存取。Silverlight 應用程式及其它網路應用程式也可以用來存取OData Client Libraries。



• Mobile Phones：
  
  現今像是Android、iOS、Windows Phone 7都支援OData client libraries。



• Business Intelligence Tools：
  
  Microsoft Excel提供資料分析工具-PowerPivot內建支援OData，其它如Tableau Desktop也支援OData。



• Custom applications：
  
  .NET Framework, Java, PHP和其它技術皆支援OData的程式。

此應用領域的範疇圍繞在OData的核心結構，圖二描述OData的核心由四個部分組成，第一為OData的資料模型，使用Entity Data Model (EDM)描述資料如同Microsoft的Entity Framework(EF)。第二為OData Protocol，將客戶端需求傳給OData Service，收到請求後再經由OData Service回應給客戶端。OData Protocol是一種互動式的Restful如同HTTP可以對資料進行新增、讀取、修改和刪除(CRUD)，OData定義的查詢語言也沿用了這種方式，且資料在OData Service傳回客戶端時可以支援XML或是JSON格式。第三為OData Client Library，可以很容易地去寫一個應用程式經由OData Protocol來存取資料，且使用特定的OData Client Library沒有嚴格要求。但大部分的OData Clients是應用程式，必須事先提供OData傳送方式的Library讓開發人員開發這些應用時可以更簡單的實現。第四為OData Service，開放式的端點讓用戶端可以存取資料，Service實作OData Protocol和利用OData抽象的資料模型，資料來源類型可能是相關的Tables或SharePoint Lists等將轉換成固定的資料形式送回給客戶端。

OData Client存取資料經由OData Service提供標準的HTTP，協定遵循REST的慣例，定義HTTP的動作，分成以下幾種：

1.GET：取得一筆或多筆資料。
2.PUT：更新存在的資料，並取代所有屬性中的值。
3.MERGE：更新存在的資料，並取代特定屬性中的值。
4.POST：創建一筆新的資料。
5.DELETE：移除一筆資料。

當客戶端指定GET傳送至一個服務端的URI加上/$metadata，如http://GET localhost/service/$metadata，服務端將回傳EDM的資料模型描述，以XML的格式回傳的結構稱之為conceptual schema definition language (CSDL)，因此客戶端可以透過$metadata了解服務端的資料模型為何。

服務所回傳的資料類型可以序列化成XML或JSON格式，若關聯式資料庫裡有兩種Tables(Customs與Orders)，客戶端指定輸入http://GET localhost/service且回傳資料類型為AtomPub格式，服務端回傳至客戶端的內容如圖三所示，服務端訂定資料庫裡的每一個資料表都會對應至一個AtomPub的集合，當客戶端使用GET方法指定存取Orders的資料表如http://GET localhost/service/Orders，客戶端取得一個Feed Document，每一個Feed Document參考至單一資料表如圖四所示，此Orders資料表每筆資料(entry)有三個欄位，以XML格式顯示。若需選擇某一筆資料可以使用http://GET localhost/service/Orders(3501)。若客戶端採取JSON的方式取得資料，同樣輸入http://GET localhost/service 及 http://GET localhost/service/Orders(3501)如圖五所示。







透過服務端所提供的URI網址，並滿足客戶端需要更精準的擷取資料內容，OData定義了查詢語言，在URI網址後附加可供選擇的查詢方法，包含以下幾種：

1.$top = n表示回傳前n筆資料。
2.$skip = n表示略過前n筆資料。
3.$format決定資料回傳的格式是JSON或是XML的AtomPub。
4.$orderby決定資料的結果排序是升冪或降冪。
5.$filter回傳符合特定表達式的資料。
6.$select回傳資料的某些欄位。

根據4、5、6這幾種查詢可以搭配運算子如大於(gt)、等於(eq)、小於(lt)來取得使用者想要的資料內容。當客戶端輸入http://GET localhost/service/Orders?$filter = CustID gt 8500000 and CustID lt 8700000，服務端會根據$filter的查詢方式，過濾掉其它欄位，以CustID>8500000及<8700000搜尋並取回符合的範圍資料，讓客戶端快速找到自己所需的資料。

然而對於OData實際層面的應用，目前很多政府相關機構使用OData資料平台的網頁讓需要的人可以去取得這些資料來源，如：行政院環境保護署環境資源資料、新北市政府資料等。本文利用這兩種機構所實現的OData資料平台進行介紹。圖六[2]為行政院環境保護署環境保護摘要資料的畫面，畫面上提供環保專案的各項內容以及支援三種資料格式(JSON、XML、CSV)供使用者選擇，點選XML後，圖七為多筆XML的環保專案網頁資訊，紅框即為OData協定的網址，此網址opendata.epa.gov.tw/ws/Data 加上(/EPR，EPR泛指一個資料代號)，再加上(/?$skip=0&$top=1000&format=xml，指OData的查詢字串，$skip=0代表不略過任何一筆資料、$top=1000代表擷取前一千筆資料內容、$format=xml代表使用者需要網址是xml的資料格式)。圖八[3]為新北市政府資料開放平台WIFI熱點的畫面，畫面上提供新北市WIFI熱點資訊以及支援三種資料格式(JSON、XML、CSV)的URL，點選XML後，圖九為多筆XML的WIFI熱點網頁資訊，紅框即為OData協定的網址，此網址data.ntpc.gov.tw/NTPC/od/data/api 加上(/IMC123，IMC123泛指一個資料代號)，再加上(/?$format=xml，指OData的查詢字串，$format=xml代表使用者需要網址是xml的資料格式)。若需要更詳細的查詢資料條件則在此網址data.ntpc.gov.tw/NTPC/od/data/api/IMC123/?$format=xml後加上(&$filter=spot_name eq [TPE-Free]捷運台北橋站-4，指OData的查詢字串，$filter=spot_name代表資料欄位spot_name，eq [TPE-Free]捷運台北橋站-4代表相等於[TPE-Free]捷運台北橋站-4的符合條件，即可被查詢出來)，如圖十所示。以上兩種網頁取得資料的方式即為OData協定網址。運用OData協定的方式及支援的查詢選擇，能便利於使用者查詢自己想要的資料內容。











OData實作技術

WCF Data Services及ASP.NET Web API皆支援OData的協定技術，針對這兩種技術進行比較與探討。

WCF Data Services(舊有名稱為"ADO.NET Data Services")，專為HTTP 端點提供簡單的資料服務，透過OData公開存取資料，存取的方式以REST為主。Data Services框架經由標準HTTP的動詞(GET、PUT、POST和DELETE)存取OData提供的服務，服務的資料以Entity Data Model(EDM)為基底，並經由OData公開之URI 定址取得相關實體資料，資料的格式為Atom(以XML交換資料格式的標準)及JSON(廣泛應用於AJAX的文字交換格式)兩種。

以圖十一顯示WCF Data Services Library的程式碼，紅框表示EDM(StockDBEntities)，WCF Data Services library透過OData的方式取得Stock的資料，在SetEntitySetAccessRule能選擇資料實體的名稱及資料的存取權限。使用Fiddler Web Debugger執行GET結果，資料格式為XML，可以從圖十二得到一筆股票交易資訊內容。圖十三透過OData提供的查詢參數$select=SYMBOL,TRADEAMT(只顯示此兩個屬性)。







在用戶端方面，WCF Data Services Library提供一個介面當作LINQ 提供者的查詢語意藉由OData來存取資料，對於.NET開發人員可以透過OData服務存取不同的資料來源。

將WCF Data Services Library作為服務端，使用Console的專案將服務端加入服務參考，透過圖十四找到服務端的定址並利用LINQ的查詢語意取得服務端的資料內容，圖十五透過Console的專案取得符合的股票交易資料。





ASP.NET Web API支援的OData的協定應用，為了使開發者在開發階段能致力於資料處理及商業邏輯的撰寫，對於資料需求需要進行排序、篩選、分頁、的處理，開發人員不需特別去撰寫因應的程式碼，只需藉由OData查詢指令即可彈性的篩選出使用者所需的資料內容。Web API OData Libraries建立在一個現今流行的Model-View-Controller (MVC)的樣式上，服務端的開發人員透過每一個客戶端需求更容易實現於controllers及在route中實現定址的服務，這些controllers滿足所有客戶端的需求並回傳適當的資料給用戶端，也可以更便捷的實現客戶端所需的新需求，也能夠產生預設的樣板程式碼來因應客戶端的需求。ASP.NET Web API的特性是以內容為主，讓客戶端可以根據想要的型態告知服務端回傳的資料類型(JSON、XML或其他格式)並序列化這些資料。

利用[Web API 2 OData Controller with actions, using Entity Framework]的Controllers，可以得到如圖十六OData的樣板，將CRUD都實現出來，結果使用Fiddler Web Debugger執行GET，資料格式為JSON，取得一筆股票交易資訊內容。





OData技術選擇上的考量

依據以上兩種OData的實作技術，我們須如何做選擇？

• 限制：WCF Data Services對於資料內容的資源侷限於兩種型態，JSON and XML。ASP.NET Web API OData可以額外支援其他型態的資料內容。



• 服務端或用戶端：WCF Data Services可以自己為服務端，也可以是客戶端，建立其他專案使用此WCF Data Services中定義的服務內容。ASP.NET Web API OData只能當作服務端。



• 用途：WCF Data Service主要是保持簡單並不想寫太多的程式碼並針對資料模型實現快速的CRUD為目的。因此若開發人員單純以開發資料存取為導向的話，WCF Data Service是一個開發的起點。ASP.NET Web API OData主要是在Controller裡新增OData的查詢語意及處理資源格式的轉換，則可以考慮使用ASP.NET Web API OData。



• 是否有彈性：WCF Data Services是以資料內容為導向，新增新的服務可以考慮ASP.NET Web API OData，因為以controller去定義各種功能。

結論

以設計的角度為出發點，無論WCF Data Services或是ASP.NET Web API OData，對於後端的開發人員而言，為了因應前端開發人員的查詢需求一直增加時，對於維護的模組會越趨肥大，後端開發人員不知道那些查詢接口是必要的。若是遇到此種情況，使用OData 也許是一個不錯的選擇，把查詢的權限都開放給前端的開發人員，這樣就能將查詢資料的需求獨立出來。

以應用層面，越來越多的客戶端應用及服務端應用在不同溝通平台皆使用 OData的協定進行資料的交換及取得。因此OData的重要性與支援的完整性是可期的。

參考資料

‧http://msdn.microsoft.com/zh-tw/windowsmobile/hh237663">
‧http://opendata.epa.gov.tw/Data/Contents/EPR/?PageIndex=1
‧http://data.ntpc.gov.tw/NTPC/od/hot">http://data.ntpc.gov.tw/NTPC/od/hot">http://data.ntpc.gov.tw/NTPC/od/hot
‧http://msdn.microsoft.com/zh-tw/library/cc668792(v=vs.110).aspx
‧http://blogs.msdn.com/b/odatateam/archive/2014/03/27/future-direction-of-wcf-data-services.aspx?utm_source=tuicool
‧http://en.wikipedia.org/wiki/Open_Data_Protocol
‧http://www.odata.org