WCF4.0新特性体验(4):Rest In WCF4.0

  1. 云栖社区>
  2. 博客>
  3. 正文

WCF4.0新特性体验(4):Rest In WCF4.0

技术小胖子 2017-11-21 18:28:00 浏览1132
展开阅读全文




  前段时间一直翻译《WCF技术内幕》,所以这个系列停滞了下来,现在翻译工作完成。现在继续来写《WCF4.0新特性体验》这个系列。今天我们来学习一下Rest WCF服务,文章会先介绍一下Rest的基本概念,以及特点,其次会介绍WCF如何实现对Rest的支持,也就是Rest WCF的底层机制。重点提到其中几个重要的类型。最后会介绍WCF4.0中对于Rest编程的改进。如此组织也是为了大家可以对Rest 以及Rest WCF 服务有个全面系统的了解。最后我也会提供一个Rest WCF的例子代码,供大家参考。

    那么我们现在就开始本节的学习,首先我们要了解什么是Rest。
【1】什么是Rest:
  REST软件架构是由Roy Thomas Fielding博士2000年在他的论文《Architectural Styles and the Design of Network- based Software Architectures》首次提出的。他提出的理论对后来的Web技术的发展产生了巨大的影响,他是许多重要Web架构标准的设计者,这些标准就是HTTP、URI等。
  1.1) Rest的英文全称是“Representational State Transfer”。中文翻译为“表述性状态转移”。REST本身只是为分布式超媒体系统设计的一种架构风格,而不是标准。
     1.2)那么如何理解“Representational State Transfer”这句话呢?下面我们来解释一下:
  • Representational :中文直译:代表的,表像的。如果把WEB 服务器端中所有的东西(数据)都看作是资源(Resource),那么呈现在用户面前(客户端)的就是资源的表像(Representation)。每一个资源都有自己的唯一标识(URI)。
  • State :中文直译:状态。首先这个状态是客户端的状态,而不是服务器端的状态(在REST 中,服务器端应该是无状态的)。那么,把State和Representation联系在一起(Representational State),可以理解成:每一个资源(Resource)在客户端的表像(Representation)就是客户端的一个状态(State)。
  • Transfer:中文直译:转移。当用户通过不同的URI访问不同的资源时,客户端的表像(Representation)也会随着变化,也就意味着客户端的状态变更(Transfer)了,连起来就是:Representational State Transfer。
  1.3)REST=老的Web规范+3个新的规范:
  REST实际上也是基于已有的Web规范集合产生的。传统的Web应用大都是BS系统,这些系统共同遵循一些老的Web规范,这些规范主要包含3条:
  • 1.客户-服务器:这种规范的提出,改善了用户接口跨多个平台的可移植性,并且通过简化服务器组件,改善了系统的可伸缩性。最为关键的是通过分离用户接口和数据存储这两个关注点,使得不同用户终端享受相同数据成为了可能。
  • 2.无状态性:无状态性是在客户-服务器约束的基础上添加的又一层规范。他要求通信必须在本质上是无状态的,即从客户到服务器的每个request都 必须包含理解该request所必须的所有信息。这个规范改善了系统的可见性(无状态性使得客户端和服务器端不必保存对方的详细信息,服务器只需要处理当 前request,而不必了解所有的request历史),可靠性(无状态性减少了服务器从局部错误中恢复的任务量),可伸缩性(无状态性使得服务器端可 以很容易的释放资源,因为服务器端不必在多个request中保存状态)。同时,这种规范的缺点也是显而易见得,由于不能将状态数据保存在服务器上的共享 上下文中,因此增加了在一系列request中发送重复数据的开销,严重的降低了效率。
  • 3.缓存:为了改善无状态性带来的网络的低效性,我们填加了缓存约束。缓存约束允许隐式或显式地标记一个response中的数据,这样就赋予了客户 端缓存response数据的功能,这样就可以为以后的request共用缓存的数据,部分或全部的消除一部分交互,增加了网络的效率。但是用于客户端缓存了信息,也就同时增加了客户端与服务器数据不一致的可能,从而降低了可靠性。
  REST在原有的架构上增加了3个新规范:统一接口、分层系统和按需代码:
  • 4.统一接口:REST架构风格的核心特征就是强调组件之间有一个统一的接口,这表现在REST世界里,网络上所有的事物都被抽象为资源,而REST 就是通过通用的链接器接口对资源进行操作。这样设计的好处是保证系统提供的服务都是解耦的,极大的简化了系统,从而改善了系统的交互性和可重用性。并且 REST针对Web的常见情况做了优化,使得REST接口被设计为可以高效的转移大粒度的超媒体数据,这也就导致了REST接口对其它的架构并不是最优的。
  • 5.分层系统:分层系统规则的加入提高了各种层次之间的独立性,为整个系统的复杂性设置了边界,通过封装遗留的服务,使新的服务器免受遗留客户端的影响,这也就提高了系统的可伸缩性。
  • 6.按需代码:REST允许对客户端功能进行扩展。比如,通过下载并执行applet或脚本形式的代码,来扩展客户端功能。但这在改善系统可扩展性的同时,也降低了可见性。所以它只是REST的一个可选的约束。
【2】Rest的特点:
    由于Rest遵守的这些规范,因此Rest架构的特点也非常的明显:
  1)REST是一种架构,而不是一个规范。
  2)REST是一种典型的Client-Server架构,但是强调瘦服务器端,服务器端只应该处理跟数据有关的操作,所有有关显示的工作都应该放在客户端。
  3)在REST架构中,服务器是无状态的,也就是说服务器不会保存任何与客户端的会话状态信息。所有的状态信息只能放在双方沟通的Message(消息)中。
  4)REST架构是幂等的,对于相同的请求,服务器返回的结果也是相同的,因此服务器端返回的结果是可以缓存的,既可以存在客户端也可以存在代理服务器端。
  5)在REST架构中,所有的操作都是基于统一的方式进行的:
  • 每个Resource都有一个唯一的ID。
  • 通过Representation(客户端)来处理Resource(服务器端)。也就是说,客户端不能直接操作服务器端的Resource,只能通过对相应的Representation的操作,并发送相应的请求,最后由服务器端来处理Resource并返回结果。
  • 客户端和服务器端传送的任何一个Message(消息),都应该是自描述的。也就是说处理这个Message所需要的上下文环境都应该包含在这个Message当中。
  • 多媒体的交互系统,客户端和服务器端传送的内容可以是文档,图片,声音等等多媒体数据,这也是一个Resource能够对应不同的Representation(例如文档,图片等)的基础。
  6)分层结构,像TCP/IP的分层结构一样,第n层使用第n-1层提供的服务并为第n+1层提供服务。在REST中,Client-Server之间加入了Proxy层和Gateway层。在这些中间层可以加入一些业务处理以外的功能,譬如:负载均衡,安全控制等等。
  7)Code-On-Demand,客户端可以访问服务器端的Resource,但并不知道如何处理服务器端返回的结果,这个处理过程的代码应该是从服务器端发送过来,然后在客户端执行,也就是说客户端的功能是根据需要动态从服务器端获得的。一个很简单的例子,Applet就是从服务器端下载然后在客户端执行的。注意,这个特性是可选的(Optional),也就是说在你的REST实现当中,可以不考虑这个特性。 
【3】Rest的优点:
      既然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。接口(客户端与我的服务交互的方式)由体系结构约束设置。
【4】Rest的设计原则:
  REST架构是针对Web应用而设计的,其目的是为了降低开发的复杂性,提高系统的可伸缩性。REST提出了如下设计准则:
(1)网络上的所有事物都被抽象为资源(resource),比如图片、音乐、视频、文字、以及服务等等;
(2)每个资源有唯一的资源标识符(resource identifier),URI定位资源; 
(3)通过通用的连接器接口(generic connector interface)对资源进行操作,比如使用 HTTP 标准动词(GET、POST、PUT 和 DELETE)的统一接口完成操作;
(4)对资源的各种操作不会改变资源标识符,URI不变;
(5)所有的操作都是无状态的(stateless)。
【5】WCF如何支持Rest:
    既然WCF也支持Rest风格,那么究竟WCF是如何实现对于Rest支持的呢?弄清这一点是学习Rest WCF的关键。
首先在WCF3.0种还没有提供对于Rest的支持,我们还只能设计传统的基于SOAP的RPC风格的WCF服务。而不能够涉及Rest WCF服务。
 为了实现于对Rest的支持,在 .NET Framework 3.5 中,WCF 在 System.ServiceModel.Web 组件中新增了编程模型和一些基础架构部件。.NET Framework 3.5 SP1 还做了几项小改进。WCF Web编程模型几个重要类型就是:
  1)WebGetAttribute 和 WebInvokeAttribute:
      我们知道,在WCF中,对于方法的调用是基于SOAP的Action的,每个客户端发送的SOAP消息都需要指定一个Action的值。这个Action的值和WCF服务的方法对应。每个WCF服务端的操作都有一个特定的Action。通过 OperationContractAttribute.Action 属性设置。看下面的SOAP消息,这个是为了调用WCF默认创建的WCF服务的GetData操作。注意Action的值:http://tempuri.org/IService1/GetData
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> 
    <s:Header> 
        <Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://tempuri.org/IService1/GetData</Action> 
    </s:Header> 
    <s:Body> 
        <GetData xmlns="http://tempuri.org/"> 
            <value>111</value> 
        </GetData> 
    </s:Body> 
</s:Envelope>
 
  在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 = "/Rest4/Get/{id}")] 
                public string GetData(string id); 
[WebInvoke(UriTemplate = "/Rest4/Add/{id}", Method = "PUT")] 
                public string AddData(string id);
   2)UriTemplate 和 UriTemplateTable:
      UriTemplate 一个表示统一资源标识符 (URI) 模板的类。可以定义服务操作的路径和HTTP动词。
  UriTemplateTable一个表示一组关联 UriTemplate 对象的类。也就是UriTemplate表。
     从上面的例子代码,我们也能看出如何使用UriTemplate 定义服务操作的URI和HTTP动词。
  3)WebHttpBinding 和 WebHttpBehavior:
  WCF Web 编程模型允许开发人员通过 HTTP 请求(这些请求使用朴素的旧的“Plain old XML”(POX) 样式消息,而不是SOAP 的消息)来公开 WCF服务。为了让客户端使用 HTTP 请求与服务进行通信,必须使用附加了 WebHttpBehavior 的 WebHttpBinding 对服务的终结点进行配置。
   WebHttpBehavior 行为与 WebHttpBinding 绑定一起使用时,支持 WCF 公开和访问 Web 样式服务。WebServiceHost 会自动将此行为添加到使用 WebHttpBinding 的终结点。例如:
         
<endpoint behaviorConfiguration="HelpBehavior" 
                                        binding="webHttpBinding" 
                                        contract="RestWcfServiceDemo.IRestService4" />
   4)WebServiceHost 和 WebServiceHostFactory:
      为了支持Web编程模型,WCF框架提供一个新的宿主类型:WebServiceHost。它是一个 ServiceHost 派生类,它是对WCF Web 编程模型的补充。如果 WebServiceHost 在服务说明中找不到终结点,则它将在服务的基址中自动为 HTTP 和 HTTPS 基址创建一个默认终结点。如果用户已在基址中明确配置终结点,则它不会自动创建终结点。WebServiceHost 会自动配置终结点的绑定,以便在安全虚拟目录中使用时与关联的 Internet 信息服务 (IIS) 安全设置一起使用。
  WebServiceHostFactory在可动态创建WebServiceHost Web宿主实例以响应传入消息的托管宿主环境中提供 WebServiceHost 的实例的工厂。
      5)WCF REST Starter Kit :
      在WCF4.0之前的版本,WCF3.5我们可以通过使用WCF开发工具包,来开发出我们的Rest WCF服务。大家可以到http://msdn.microsoft.com/en-us/netframework/cc950529.aspx官方网站下载安装包。这里也有关于Rest WCF的最新的资料。
【6】WCF4.0对Rest的改进:
      在WCF4.0中,对于Rest  WCF服务的支持做了一些改进,比如错误处理,消息格式(XML, JSON, ATOM, text, binary等等)、简化GET/PUT 请求消息的处理,当然两个比较重要的改进就是:帮助页面、Http缓存。
  1)HelpPage(帮助页面):
      我们知道,Rest服务没有WSDL服务元数据,因此客户端不能获得服务的元数据信息,更不能产生客户端代码。因此就需要一种途径告诉客户端调用服务的方式。这些信息在WCF4.0就通过HelpPage(帮助页面)来显示给客户端。其实这个帮助页面在WCF3.5里也已经支持,但是WCF4.0做了改进。我们可以看一下例子。
     首先我们来定义一个Rest服务,它包含4个操作。代码如下:
[WebGet(UriTemplate = "/Rest4/Get/{id}")] 
                public string GetData(string id) 
                { 
                        return "Hello Rest"; 
                } 
                [WebInvoke(UriTemplate = "/Rest4/Add/{id}", Method = "PUT")] 
                public string AddData(string id) 
                { 
                        return "Hello Rest"; 
                } 
                [WebInvoke(UriTemplate = "/Rest4/Update/{id}", Method = "POST"),] 
                public string UpdateData(string id) 
                { 
                        return "Hello Rest"; 
                } 
                [WebInvoke(UriTemplate = "/Rest4/Delete/{id}", Method = "DELETE")] 
                public string DeleteData(string id) 
                { 
                        return "Hello Rest"; 
                }
   启用帮助页面也很简单,就是在WCF服务行为里定义属性,然后启用helpEnabled="true" 。代码如下:
       
<endpointBehaviors> 
             <behavior name="HelpBehavior"> 
                 <webHttp helpEnabled="true" /> 
                    </behavior> 
</endpointBehaviors>
     启动WCF服务,我们查看服务的帮助信息如下:
  我们可以清楚地看到,每个操作的的信息,以及调用的URI。当然我们也可以点击Method一列的连接,查看每个方法的详细信息。比如我们查看Post方法。结果如图:
这些信息很大程度减少了我们犯错的机会,可以帮助我们调试Rest WCF服务,以及快速编写客户端代码。
  2)Http Cache(Http缓存)
   Rest的一大优点就是减少Http缓存的使用量,因而提升服务的性能。之前我们需要通过控制Http请求和应答消息头来实现对于缓存的控制。现在在WCF4.0中,提供了一种新的类型AspNetCacheProfile。来配置每个操作的http缓存。CachingParameterInspector类型会处理底层缓存设置的工作。 [AspNetCacheProfile] 也是建立在标准的ASP.NET 输出缓存机制上。在WCF4.0中我们可以直接给每个操作添加这个属性。但是前提是我们要先定义这个缓存。然后在应用到操作上。例如,我们在配置文件中指定缓存的设置信息:
 
<system.web> 
        <caching> 
            <outputCacheSettings> 
                <outputCacheProfiles> 
                    <add name="CacheFor30Seconds" duration="30" varyByParam="format" /> 
                </outputCacheProfiles> 
            </outputCacheSettings> 
        </caching> 
    </system.web>
     然后在操作上应用这个属性,代码如下:
      
    [AspNetCacheProfile("CacheFor30Seconds")] 
                [WebGet(UriTemplate = "/Rest4/Get/{id}")] 
                public string GetData(string id) 
                { 
                        return "Hello Rest"; 
                }
     这样就实现对于Http缓存的设置。
【7】总结
(1)整体上来说,Web、HTTP和URI仅仅是REST风格的一个主要实现。
(2)WCF对于Rest的支持,也是通过基本的Web编程模型来实现的。也就是从SOAP Action到URI+Http动词的转变。
(3)WCF4.0对于Rest 服务的支持在帮助页面(HelpPage)和Http缓存上做了改进,方便我们对于Rest服务操作Http缓存的配置。
(4)为了方便大家理解 Rest WCF服务,以及WCF4.0对于 Rest的改进,我写了一个Demo程序,共大家下载参考。/Files/frank_xl/RestWcf4.0ServiceDemoByFrankXuLei.zip.(代码里PUT应该对应ADD操作,POST对应Update操作。大家注意。我个人标注错误。现在注明一下)。
也欢迎留言交流。
参考资料:
1.http://blog.csdn.net/WCFToolsBloggers/archive/2008/09/02/2865038.aspx
2.http://msdn.microsoft.com/en-us/magazine/dd315413.aspx
3.http://www.infoq.com/cn/articles/rest-introduction
4.http://hi.baidu.com/notesjava/blog/item/2860faf2c889fe5b352acc18.html
5.http://msdn.microsoft.com/zh-cn/library/system.servicemodel.description.webhttpbehavior.aspx
6.http://msdn.microsoft.com/zh-cn/library/system.servicemodel.webhttpbinding.aspx
7.http://msdn.microsoft.com/zh-cn/library/system.servicemodel.activation.webservicehostfactory.aspx



 本文转自 frankxulei 51CTO博客,原文链接:http://blog.51cto.com/frankxulei/320287,如需转载请自行联系原作者


网友评论

登录后评论
0/500
评论
技术小胖子
+ 关注