WCF4.0新特性体验
前段时间一直翻译《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）。
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。
双击代码全选 12345678910 <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 等）。例如：
双击代码全选 1234 [WebGet(UriTemplate = "/Rest4/Get/{id}")] public string GetData(string id); [WebInvoke(UriTemplate = "/Rest4/Add/{id}", Method = "POST")] 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 对服务的终结点进行配置。
