提供RESTful服務

標籤：

RESTful廣泛運用於互連網服務，而在公司專屬應用程式中，大部分情境仍然是RPC服務，這是由於公司專屬應用程式的業務複雜性造成的。但是基於SOAP的RPC服務也存在很多的弊端，比如服務非同步處理比較麻煩，大部分RPC服務仍然是阻塞性質的，即使在.net 4.5的今天，非同步編程已經通過asyn/await極大簡化的情況下。其中的原因也挺複雜的，有興趣瞭解的可參考以下文章：http://blogs.msdn.com/b/pfxteam/archive/2012/03/24/10287244.aspx

簡單得將以前的RPC服務進行非同步封裝是沒有必要的。

 

因此，在適當場合可以考慮提供REST服務，當然REST服務與RPC服務的區別，優劣並不是僅體現在這方面，還有其它諸如跨平台性、可擴充性等方面，因為這兩者的協議是完全不一樣的，REST畢竟是基於HTTP協議，幾乎適用於當前所有平台。

 

其實microsoft早在.net framework 3.5時期，就已經提供了REST的實現，當時是基於WCF技術，通過對操作增加WebGetAttribute,WebInvokeAttribute來實現GET,POST操作。不過由於其還是基於WCF架構，通過其管道來進行服務調用，還需要配置對應的webHttpBinding，因此個人感覺在.net 3.5時期，REST並未得到廣泛應用，當然這也可能是由於我並未從事互連網行業的緣故。

到了.net framework 4時期，microsoft提供了web api這一套架構，用於支援REST服務的開發，最近段時間使用了下，覺得還是挺方便地，對HTTP協議提供了很好的支援，包括可以自訂Request,Response的Header,Content等等，目前我需要的功能，這套架構都能很好地提供支援。並且，服務能夠直接通過瀏覽器，如Chrome,FireDebug等等調試，同時，與WcfTestClient類似，我們也可以用Fiddler之類的調試工具進行很方便的調試。

使用web api架構是很簡單的，直接參照ASP.NET的入門文檔（http://www.asp.net/web-api/overview/getting-started-with-aspnet-web-api/tutorial-your-first-web-api），即可很快地搭建起來一個架子，並成功地提供REST服務，在這裡我就不重複貼出實現代碼了，其關鍵點如下：

1：通過NuGet擷取Microsoft.AspNet.WebApi.SelfHost包，因為我一般使用自宿主模式，很少寄宿在IIS；

2：對需要提供服務的資源(resource)建立對應的controller，在REST中，一切的核心就是resource，圍繞resource提供GET,POST,PUT,DELETE等操作，這點與RPC有很大區別，思維模式的轉變很大;

3：提供宿主，運行即可，ASP.NET的入門文檔中，宿主是Console Application，實際運行環境中，我一般寄宿在Windows service中，其實是非常類似的。

做完以上三部，咱們的REST服務就已經向外提供HTTP服務了。注意這裡第3點有個需要注意的小細節，必須以管理員權限運行宿主進程，否則無法監聽URL連接埠。

 

但正如上文第2點中所說，REST真正的痛點，個人感覺並不在技術實現上，其實是一種思維模式的徹底轉變，由長久以來RPC服務中商務活動流程為中心的服務設計思想，轉變為資源為中心的設計思想，在這樣的思維模式下去對我們實際情境中的各種服務進行與以往相比顛覆性的重新設計，才是REST真正的痛點所在。

 

這篇隨筆先寫寫這些，算是個基礎入門，架子打起來算是勉強摸了下門檻，之後的工作才是任重道遠。

提供RESTful服務