你的位置:首页 > ASP.net教程

[ASP.net教程]WCF学习之旅—实现REST服务(二十二)


 一、什么是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的资源表述形式可以是

       但是REST不是万能的。操作无状态也会带来巨大的安全问题,如何授权和验证用户?如果要求每次请求都包含完整的身份和验证信息,又如何避免信息泄漏?复杂的功能挑战架构的易用性,这就需要在性能与功能间权衡,究竟该用REST还是SOAP。  

二、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 库(当然,

  6)简易性与其他优点相比,这一优点更主观一些,不同的人可能有不同的感受。对我而言,使用 REST 的简易性涉及到代表资源的 URI 和统一接口。作为一名 Web 冲浪高手,我理解在浏览器中输入不同的 URI 可以得到不同的资源(有时也被称为 URI 或 URL 黑客,但绝无恶意)。由于有多年使用 URI 的经验,所以为资源设计 URI 对我来说得心应手。使用统一接口简化了开发过程,因为我不必为每个需要建立的服务构建接口、约定或 API。接口(客户端与我的服务交互的方式)由体系结构约束设置。

 

三、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

        与其他绑定不同的是:必须使用WebHttpBehavior对服务的终结点进行配置。还要求使用WebGetAttribute或WebInvokeAttribute属性将各个服务操作映射到 URI,同时定义调用和返回结果的消息格式。

 

   WCF Web 编程模型允许开发人员通过 HTTP 请求(这些请求使用朴素的旧的“Plain old 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 的实例的工厂。