一、什么是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。
二、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。接口（客户端与我的服务交互的方式）由体系结构约束设置。
三、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 的实例的工厂。