REST一下吧~ 從Web Service到RESTful WCF的心情
前陣子我的技術前輩Ruddy在MSDN研討會中，介紹了WCF在.NET 3.5上的一些功能增強，其中一個相當重要的部分是WCF對REST的支持。
你會發現，最近這一兩年，REST這個字眼常常看到，儘管他是Dr. Roy Fielding在2000年時候就提出的，但是我想真正開始紅起來，是因為Amazon和Yahoo都開始拋棄Web Service改提供REST形式的服務，且RoR和一些其他陣營的開發工具都大張旗鼓的支援...所以，就紅了...-_-'''
而.NET似乎總是比其他陣營遲緩(或是嚴謹?)一點，不過仗著後台硬(現金多)，對於各種技術的支援也總是後發先至，你會看到REST突然之間在.NET開發技術裡佔了一個不小的位置，WCF支持它、ADO.NET Data Service也支持它...
由於未來我會花一點時間談談ADO.NET Data Service(因為我要在Silverlight當中叫用它)，你會發現這個服務也是建立在REST的概念上，透過相當簡單的URL來存取遠端的資料庫。
在過去，這不是Web Service的主要工作嗎? 是的，在2002年，我寫的第一本ASP.NET書籍當中，還努力的鼓催Web Service的使用，我還記得那時候提的範例，是一個郵遞區號的Web Service呼叫，我還說，如果郵局提供此Web Service，全台灣(或全世界)使用到台灣郵遞區號的程式或網站，就再也不用自己去下載郵局提供的3+2郵遞區號對照表(如果我沒記錯是Excel格式)，還要手動轉成DB，還要常常自己上網更新，因為台灣的路名、郵遞區號等資訊常常變...透過Web Service，我們可以輕易的達成網站間或是應用程式間的資料交換，把資訊串起來，讓SOA的理想更有可能輕易實現。
但是，過了那麼多年，Web Service雖然成功的在企業中被使用，但是多半還是在同質的多系統之間進行資料交換，例如在.NET寫的HR或ERP系統之間交換資料。很少看到我們真正期待的在異質系統之間進行資料交換。Web Service儘管是RPC(遠端程序呼叫:remote procedure call)一個相當不錯的解決方案，但是鼓催了多年，卻始終很難達成異質系統之間的資料交換。why?
原因有很多，安全性、效能、使用上的便利性...等，先撇開這個不談，無法在多異質系統之間進行資料交換的這個問題，一部分的原因是Web Service採用的XOAP和XML-RPC作為骨架，相對而言還是太過複雜，為了調用遠端的服務你必須先知道服務的位置，以及Web Method，需要知道要傳入的參數和回傳參數的數量、種類、型別、意義...才能夠真正存取該資源。
例如： http://www.studyhost.com/ZipCodeSrv.asm?GetCode
上面這個URL我們只知道有一個位於http://www.studyhost.com/的服務ZipCodeSrv，(似乎)可以用來取得郵遞區號，問題是要怎麼傳遞資料?從URL上都看不到...
而REST正如字面上的意思這幾個字，可以讓開發人員好好休養生息一下，它用簡單到不能再簡單的URL，來表達存放在網路上的資源，並且讓開發人員可以進行存取。
例如，如果你想要公開Northwind資料庫，讓遠端的開發人員可以透過REST方式存取，提供新增、修改、刪除、查詢等功能，那可能只需要底下的URL：
(GET) http://Store.studyHost.com/products
上面這串網址可以傳回所有的商品資料
而
(GET) http://Store.studyHost.com/products/A0213
則可以傳回編號為A0213的產品的相關資料
此外，開發人員對於資料庫中的記錄所會進行的查找、新增、修改、刪除...等動作，剛好可以對應到HTTP所提供的GET、PUT、POST和DELETE方法，看起來就是很簡單的感覺...
最近正式推出的ADO.NET Data Service，在查找資訊的時候，也是採用REST-baseed技術，以同樣簡單的方式讓開發人員可以輕易的存取遠端的資源(資料庫)的內容。
回頭看，整個REST技術的目的：
1.提供相較於以SOAP為based的Web Service更簡單的遠端程序調用方式。
2.不在現有的HTTP技術上疊床架屋，就是用相同於HTTP協定的各種方法(GET、PUT、POST和DELETE)處理完所有的資料存取。
3.在異質系統之間的資料交換將變得更加容易，任何平台都可以叫用。
基於這種種的原因，WCF也開始支援開發人員撰寫REST風格的遠程呼叫方法，.NET 3.5 SP1中的ADO.NET Data Service根本就基於REST技術架構出的服務，而ASP.NET MVC和Dynamic Data技術所採用的URL Routing機制，也有REST技術的影子...
URL不再只是指向某一個頁面，而是指向某個資源的存在，並且我們可以透過URL來操作(新增、修改、存取)這個資源，而MVC架構中的URL更可以視為指向某一個服務(Service)或行為(action)，整個結論就是，簡單、直接、有效...
會寫這一篇，是因為Ruddy前輩在上個月講WCF和REST的時候，我還不是很能被說服，我覺得Web Service用的好好的，微軟沒事幹嘛多弄個REST來鬧場? 這不是屬於第三陣營的技術嗎? 我需要花時間下去跟大家介紹???
結果經過了一段時間，有天早上起來，我覺悟了，我發現我錯了，我想通了，看起來，REST還真的會被微軟支援，在異質系統之間的資料交換，目前確實沒什麼比REST還方便的，連WCF和ADO.NET Data Service都支援了，我還在猶豫什麼... 我的Silverlight 2.0(其實也包含WinForm)已經全面的支援 以 REST 為基礎的ADO.NET Data Service呼叫，而現在拿WCF來開發RESTful的RPC輕鬆到不行，如果身為ASP.NET書籍作者的自己不寫個一兩篇REST豈不是遜掉了嗎?
所以，這一篇，是心情轉折，下一篇，我要來介紹如何透過WCF開發RESTful的RPC...
你會發現，最近這一兩年，REST這個字眼常常看到，儘管他是Dr. Roy Fielding在2000年時候就提出的，但是我想真正開始紅起來，是因為Amazon和Yahoo都開始拋棄Web Service改提供REST形式的服務，且RoR和一些其他陣營的開發工具都大張旗鼓的支援...所以，就紅了...-_-'''
而.NET似乎總是比其他陣營遲緩(或是嚴謹?)一點，不過仗著後台硬(現金多)，對於各種技術的支援也總是後發先至，你會看到REST突然之間在.NET開發技術裡佔了一個不小的位置，WCF支持它、ADO.NET Data Service也支持它...
由於未來我會花一點時間談談ADO.NET Data Service(因為我要在Silverlight當中叫用它)，你會發現這個服務也是建立在REST的概念上，透過相當簡單的URL來存取遠端的資料庫。
在過去，這不是Web Service的主要工作嗎? 是的，在2002年，我寫的第一本ASP.NET書籍當中，還努力的鼓催Web Service的使用，我還記得那時候提的範例，是一個郵遞區號的Web Service呼叫，我還說，如果郵局提供此Web Service，全台灣(或全世界)使用到台灣郵遞區號的程式或網站，就再也不用自己去下載郵局提供的3+2郵遞區號對照表(如果我沒記錯是Excel格式)，還要手動轉成DB，還要常常自己上網更新，因為台灣的路名、郵遞區號等資訊常常變...透過Web Service，我們可以輕易的達成網站間或是應用程式間的資料交換，把資訊串起來，讓SOA的理想更有可能輕易實現。
但是，過了那麼多年，Web Service雖然成功的在企業中被使用，但是多半還是在同質的多系統之間進行資料交換，例如在.NET寫的HR或ERP系統之間交換資料。很少看到我們真正期待的在異質系統之間進行資料交換。Web Service儘管是RPC(遠端程序呼叫:remote procedure call)一個相當不錯的解決方案，但是鼓催了多年，卻始終很難達成異質系統之間的資料交換。why?
原因有很多，安全性、效能、使用上的便利性...等，先撇開這個不談，無法在多異質系統之間進行資料交換的這個問題，一部分的原因是Web Service採用的XOAP和XML-RPC作為骨架，相對而言還是太過複雜，為了調用遠端的服務你必須先知道服務的位置，以及Web Method，需要知道要傳入的參數和回傳參數的數量、種類、型別、意義...才能夠真正存取該資源。
例如： http://www.studyhost.com/ZipCodeSrv.asm?GetCode
上面這個URL我們只知道有一個位於http://www.studyhost.com/的服務ZipCodeSrv，(似乎)可以用來取得郵遞區號，問題是要怎麼傳遞資料?從URL上都看不到...
而REST正如字面上的意思這幾個字，可以讓開發人員好好休養生息一下，它用簡單到不能再簡單的URL，來表達存放在網路上的資源，並且讓開發人員可以進行存取。
例如，如果你想要公開Northwind資料庫，讓遠端的開發人員可以透過REST方式存取，提供新增、修改、刪除、查詢等功能，那可能只需要底下的URL：
(GET) http://Store.studyHost.com/products
上面這串網址可以傳回所有的商品資料
而
(GET) http://Store.studyHost.com/products/A0213
則可以傳回編號為A0213的產品的相關資料
此外，開發人員對於資料庫中的記錄所會進行的查找、新增、修改、刪除...等動作，剛好可以對應到HTTP所提供的GET、PUT、POST和DELETE方法，看起來就是很簡單的感覺...
最近正式推出的ADO.NET Data Service，在查找資訊的時候，也是採用REST-baseed技術，以同樣簡單的方式讓開發人員可以輕易的存取遠端的資源(資料庫)的內容。
回頭看，整個REST技術的目的：
1.提供相較於以SOAP為based的Web Service更簡單的遠端程序調用方式。
2.不在現有的HTTP技術上疊床架屋，就是用相同於HTTP協定的各種方法(GET、PUT、POST和DELETE)處理完所有的資料存取。
3.在異質系統之間的資料交換將變得更加容易，任何平台都可以叫用。
基於這種種的原因，WCF也開始支援開發人員撰寫REST風格的遠程呼叫方法，.NET 3.5 SP1中的ADO.NET Data Service根本就基於REST技術架構出的服務，而ASP.NET MVC和Dynamic Data技術所採用的URL Routing機制，也有REST技術的影子...
URL不再只是指向某一個頁面，而是指向某個資源的存在，並且我們可以透過URL來操作(新增、修改、存取)這個資源，而MVC架構中的URL更可以視為指向某一個服務(Service)或行為(action)，整個結論就是，簡單、直接、有效...
會寫這一篇，是因為Ruddy前輩在上個月講WCF和REST的時候，我還不是很能被說服，我覺得Web Service用的好好的，微軟沒事幹嘛多弄個REST來鬧場? 這不是屬於第三陣營的技術嗎? 我需要花時間下去跟大家介紹???
結果經過了一段時間，有天早上起來，我覺悟了，我發現我錯了，我想通了，看起來，REST還真的會被微軟支援，在異質系統之間的資料交換，目前確實沒什麼比REST還方便的，連WCF和ADO.NET Data Service都支援了，我還在猶豫什麼... 我的Silverlight 2.0(其實也包含WinForm)已經全面的支援 以 REST 為基礎的ADO.NET Data Service呼叫，而現在拿WCF來開發RESTful的RPC輕鬆到不行，如果身為ASP.NET書籍作者的自己不寫個一兩篇REST豈不是遜掉了嗎?
所以，這一篇，是心情轉折，下一篇，我要來介紹如何透過WCF開發RESTful的RPC...
留言