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 的实例的工厂。