WCF學習之旅—實現REST服務（二十二）

 1、什麼是REST

       表述性狀態轉移（Representational State Transfer,REST），不是一種標準，而是一種軟件架構風格。

       基於REST的服務與基於SOAP的服務相比，性能、效率和易用性上都更高，而SOAP協議很是的複雜和不透明。REST受到愈來愈多的Web服務供應商歡迎。目前大部分供應商，如淘寶、騰訊、google、Amazon等都提供REST風格的服務。

 REST的主要原則是：

 1.網絡上的全部事物均可被抽象爲資源；

 2.每一個資源都有一個惟一的資源標識符URI；

 3.使用標準方法操做資源；

 4.全部的操做都是無狀態的；

 5.經過緩存來提升性能。

        REST (Representation State Transfer) 描 述了一個架構樣式的網絡系統，好比Web應用程序。它首次出如今2000年 Roy Fielding 的博士論文中，他是HTTP規範的主 要編寫者之一。REST 指的是一組架構約束條件和原則。知足這些約束條件和原則的應用程序或設計就是 RESTful。

       使用REST作爲業務邏輯接口是由於，從客戶端到服務器的每一個請求都必須包含理解請求所必需的信息。若是服務器在請求之間的任什麼時候間點重啓，客戶端不會得 到通知。此外，無狀態請求能夠由任何可用服務器回答，這十分適合雲計算之類的環境。客戶端能夠緩存數據以改進性能。

        在服務器端，應用程序狀態和功能能夠分爲各類資源。資源是一個有趣的概念實體，它向客戶端公開。資源的例子有：應用程序對象、數據庫記錄、算法等等。每一個 資源都使用 URI (Universal Resource Identifier) 獲得一個唯一的地址。客戶端使用的是標準的 HTTP協議進行資 源訪問，同時還可使用標準的HTTP方法，好比 GET、PUT、POST 和 DELETE。

       REST的一個重要原則是系統分層，這表示組件沒法瞭解它與之交互的中間層之外的組件。經過將系統的某些功能限制在某一層，由此能夠限制整個系統的複雜性，促進了底層的獨立性。

       當 REST 架構的約束條件做爲一個總體應用時，將生成一個能夠擴展到大量客戶端的應用程序。它還下降了客戶端和服務器之間的交互延遲。統一界面簡化了整個系統架構，改進了子系統之間交互的可見性。REST 簡化了客戶端和服務器的實現。

       REST的資源表述形式能夠是XML、HTML、JSON，或者其餘任意的形式，這取決於服務提供商和消費服務的用戶。

       可是REST不是萬能的。操做無狀態也會帶來巨大的安全問題，如何受權和驗證用戶？若是要求每次請求都包含完整的身份和驗證信息，又如何避免信息泄漏？複雜的功能挑戰架構的易用性，這就須要在性能與功能間權衡，究竟該用REST仍是SOAP。  

2、Rest的優勢

　　1）緩存，使用 HTTP 向 RESTful 端點申請數據時，用到的 HTTP 動詞是 GET。對於 GET 請求響應中返回的資源，能夠用多種不一樣的方式進行緩存。Conditional GET 就是可供選擇的一種實現細節，客戶端能夠向服務驗證他的數據是否爲最新版本；RESTful 端點能夠經過它進一步提升速度和可伸縮性。

　　2）擴展，REST 鼓勵每項資源包含處理特殊請求所需的全部必要狀態。知足這一約束時，RESTful 服務更易於擴展且能夠沒有狀態。

　　3)反作用，使用 GET 請求資源，RESTful 服務應該沒有反作用（遺憾的是，與其餘一些 REST 約束相比，這一約束更容易被打破）。

　　4）冪等，統一接口另外兩個經常使用到的主要 HTTP 動詞是 PUT 和 DELETE。用戶代理想要修改資源時最常使用 PUT，DELETE 能夠自我描述。要點（也就是「冪等」一詞所強調的）是您能夠對特殊資源屢次使用這兩個動詞，效果與首次使用同樣——至少不會有任何其餘影響。構建可靠的分 布式系統時（即錯誤、網絡故障或延遲可能致使屢次執行代碼），這一優勢可提供保障。

　　5）互操做性許，多人將 SOAP 捧爲創建客戶端-服務器程序最具互操做性的方法。但一些語言和環境至今仍沒有 SOAP 工具包。有一些雖然有工具包，但採用的是舊標準，不能保證與使用更新標準的工具包可靠溝通。對於大多數操做，REST 僅要求有 HTTP 庫（固然，XML 庫一般也頗有幫助），它的互操做性確定強過任何 RCP 技術（包括 SOAP）。

　　6）簡易性與其餘優勢相比，這一優勢更主觀一些，不一樣的人可能有不一樣的感覺。對我而言，使用 REST 的簡易性涉及到表明資源的 URI 和統一接口。做爲一名 Web 衝浪高手，我理解在瀏覽器中輸入不一樣的 URI 能夠獲得不一樣的資源（有時也被稱爲 URI 或 URL 黑客，但絕無惡意）。因爲有多年使用 URI 的經驗，因此爲資源設計 URI 對我來講駕輕就熟。使用統一接口簡化了開發過程，由於我沒必要爲每一個須要創建的服務構建接口、約定或 API。接口（客戶端與個人服務交互的方式）由體系結構約束設置。

 

3、WCF如何支持Rest

       WCF如何實現對於Rest支持的呢？弄清這一點是學習Rest WCF的關鍵。

       爲了實現於對Rest的支持，在 .NET Framework 中，WCF 在 System.ServiceModel.Web 組件中新增了編程模型和一些基礎架構部件。WCF Web編程模型幾個重要類型就是：

　  1)  WebGetAttribute 和 WebInvokeAttribute:

       咱們知道，在WCF中，對於方法的調用是基於SOAP的Action的，每一個客戶端發送的SOAP消息都須要指定一個Action 的值。這個Action的值和WCF服務的方法對應。每一個WCF服務端的操做都有一個特定的Action。經過 OperationContractAttribute.Action 屬性設置。

　　在Rest WCF中，基於Action的方法調用轉變爲了基於URI+Http動詞的調用。也就是SOAP Action=URI+Http動詞。

　　這種映射會由WebHttpDispatchOperationSelector 類型來完成，它會把客戶端請求的URI+Http動詞，映射到特定的服務方法上。

　　WebGetAttribute 告訴服務方法應該響應 HTTP GET 請求。

　　WebInvokeAttribute 默認映射爲 HTTP POST，但可將WebInvokeAttribute.Method 屬性設置爲支持全部其餘 HTTP 動詞（PUT 和 DELETE 等）。例如：

     

    

   [WebGet(UriTemplate = "/Books/Get/{BookId}", BodyStyle = WebMessageBodyStyle.Bare)]
          [OperationContract]
          List<Books> GetBook(string BookId);

 

        [WebInvoke(Method = "POST", UriTemplate = "/Books/Add", BodyStyle = WebMessageBodyStyle.Bare)]
         [OperationContract]
         Result AddBook(Books book);

 　　2)  UriTemplate 和 UriTemplateTable:

      UriTemplate 一個表示統一資源標識符 (URI) 模板的類。能夠定義服務操做的路徑和HTTP動詞。

　　UriTemplateTable一個表示一組關聯 UriTemplate 對象的類。也就是UriTemplate表。

      從上面的例子代碼，咱們也能看出如何使用UriTemplate 定義服務操做的URI和HTTP動詞。

 

      3)   WebHttpBinding 和 WebHttpBehavior:

       WebHttpBinding容許開發人員經過 HTTP 請求（這些請求使用「Plain old XML」(POX) 樣式消息，而不是使用基於 SOAP 的消息）來公開 WCF Web 服務，能夠很便利的實現REST。

        與其餘綁定不一樣的是：必須使用WebHttpBehavior對服務的終結點進行配置。還要求使用WebGetAttribute或WebInvokeAttribute屬性將各個服務操做映射到 URI，同時定義調用和返回結果的消息格式。

 

　 　WCF Web 編程模型容許開發人員經過 HTTP 請求（這些請求使用樸素的舊的「Plain old XML」(POX) 樣式消息，而不是SOAP 的消息）來公開 WCF服務。爲了讓客戶端使用 HTTP 請求與服務進行通訊，必須使用附加了 WebHttpBehavior 的 WebHttpBinding 對服務的終結點進行配置。

 　　WebHttpBehavior 行爲與 WebHttpBinding 綁定一塊兒使用時，支持 WCF 公開和訪問 Web 樣式服務。WebServiceHost 會自動將此行爲添加到使用 WebHttpBinding 的終結點。例如：

        

<system.serviceModel>
    <bindings>
       <webHttpBinding>
         <binding name="RestWebBinding">

         </binding>

       </webHttpBinding>

     </bindings>
    <behaviors>
      <serviceBehaviors>
        <behavior name="metadataBehavior">
          <serviceMetadata httpGetEnabled="true" httpGetUrl="http://127.0.0.1:8888/BookService/metadata" />
          <serviceDebug includeExceptionDetailInFaults="True" />

        </behavior>
          <behavior name="RestServiceBehavior">

         </behavior>

      </serviceBehaviors>
       <endpointBehaviors>
         <behavior name="RestWebBehavior">
           <!--這裏必須設置-->

           <webHttp />

         </behavior>

       </endpointBehaviors>
    </behaviors>

    <services>   

      <service name="SCF.WcfService.BookRestService" behaviorConfiguration="RestServiceBehavior">
         <endpoint address="http://127.0.0.1:8888/" behaviorConfiguration="RestWebBehavior"
                   binding="webHttpBinding" bindingConfiguration="RestWebBinding" contract="SCF.Contracts.IBookRestService">
         </endpoint>
       </service>
    </services>
  </system.serviceModel>

 

 

 　　4)WebServiceHost 和 WebServiceHostFactory:

      爲了支持Web編程模型，WCF框架提供一個新的宿主類型：WebServiceHost。它是一個 ServiceHost 派生類，它是對WCF Web 編程模型的補充。若是 WebServiceHost 在服務說明中找不到終結點，則它將在服務的基址中自動爲 HTTP 和 HTTPS 基址建立一個默認終結點。若是用戶已在基址中明確配置終結點，則它不會自動建立終結點。WebServiceHost 會自動配置終結點的綁定，以便在安全虛擬目錄中使用時與關聯的 Internet 信息服務 (IIS) 安全設置一塊兒使用。

　　WebServiceHostFactory在可動態建立WebServiceHost Web宿主實例以響應傳入消息的託管宿主環境中提供 WebServiceHost 的實例的工廠。