.NET Walker

　　在上周 『從Web Service到RESTful WCF的心情』 一文中，我提到了對REST的感想，而這一篇，則是介紹.NET 3.5 中對REST的支援，說明如何透過WCF開發RESTful服務，不過，當.NET開發人員要透過WCF來開發RESTful的服務之前，有一些基本的觀念需要釐清。所謂的REST技術，其精神是透過Uri來描述存在於網際網路上的資源，例如： 　　　　http://www.studyhost.com/Eshop/Products/Nokia5130 　　上面這串網址可表示一個產品資料表中的產品，產品名稱為Nokia5130，若我們想取得資料，可透過HTTP GET方法，以上述網址來取得。 　　若我們想刪除這個資料，則一樣是上面這串網址，但是對IIS伺服器送出的動作則是HTTP DELETE。如果我們想建立一筆新的資料，則可透過HTTP POST方法，至於要修改，則透過HTTP PUT方法。 　　也就是說，描述資源是透過Uri，而對資源要進行的動作，則是透過HTTP verb來進行。有了這樣的觀念之後，我們就可以開始嘗試建議建立RESTful的 WCF服務。我們建立出的WCF服務，只需要遵循上述的 REST風格，即可讓所有的開發人員存取。　　 　　一直說REST風格而不說REST規格，主要的原因是REST並非是一種哪一個機構或是協會設計出來的規格，由於架構簡單，它僅僅是一種設計風格，就是兩個要點，用Uri來描述資源位置，用四種Http Verbs(包含GET, POST, DELETE, PUT)來決定對這個資源要進行的動作，甚至當我們用調用某一個RESTful的服務時，該服務回傳的資料也沒有一定要以XML型別回傳，也可以是單純的文字或是HTML。總而言之，它就是簡單導向。 　　而HTTP Verbs到底是什麼呢?這對於絕大部分時間僅僅使用瀏覽器的開發人員來說，可能有點陌生，HTTP Verbs是HTTP協議定義出的規格，HTTP共有八種動作，包含：HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS, CONNECT，過去我們常用且熟悉的應該是HTTP GET和HTTP POST，當你在瀏覽器上輸入一個網址，對於IIS伺服器下的指令其實就是HTTP GET，而當你在瀏覽器上按下某一個Submit按鈕(或...

　　前陣子我的技術前輩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? 　　原因有很多，安全性、效能、使用上的便...