WCF学习之旅—实现REST服务（二十二）

最新推荐文章于 2019-01-08 07:26:47 发布

weixin_30608131

最新推荐文章于 2019-01-08 07:26:47 发布

阅读量74

点赞数

文章标签：系统架构 json 数据库

原文链接：http://www.cnblogs.com/chillsrc/p/5806718.html

版权

一、什么是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 的实例的工厂。

转载于:https://www.cnblogs.com/chillsrc/p/5806718.html