REST服务介绍

REST 产生背景

Web服务和WCF它们虽然使用了HTTP协议，但是其实建立在 SOAP 上，以至于我们提到 Web 服务就会想到 SOAP，也就是说，他们并没有直接建立在 HTTP上，仅仅使用HTTP作为一种夹带其他的应用协议穿越防火墙的方法，可以说，他们没有充分挖掘并利用HTTP协议。
在HTTP协议中，消息通过在那些资源的表述上的转移和操作，来对资源执行一些动作，从而反映出Web架构的语义，因此使用这个非常简单的接口来获得广泛的功能是完全有可能的。
表述化状态转移 （Representational State Transfer，简称REST ）是Roy Thomas Fielding博士在2000年他的论文中提出来的一种软件架构风格。REST软件架构风格迅速成为当今世界上最成功的互联网的超媒体分布式系统。它让人们真正理解我们的网络协议HTTP本来面貌。它正在成为网络服务的主流技术。
REST软件架构是一个抽象的概念，是一种为了实现这一互联网的超媒体分布式系统的行动指南。
利用任何的技术都可以实现这种理念。而实现这一软件架构最著名的就是HTTP协议。通常我们把REST也写作为REST/HTTP，在实际中往往把REST理解为基于HTTP的REST软件架构。
优点：
基于SOAP的Web Service实现技术和相关代码，虽然较为成熟，且安全性较好，但是使用门槛较高，而且在大并发情况下可能会有性能问题。目前在三种主流的Web服务实现方案中，因为REST模式与复杂的SOAP和XML-RPC相比更加简洁，越来越多的Web服务开始采用REST风格设计和实现。

什么是REST？

表述状态转移： REST （Representational State Transfer），采用Web 服务使用标准的 HTTP 方法 (GET/PUT/POST/DELETE) 来抽象所有 Web 系统的服务能力，它是一种软件架构风格，一种针对网络应用的开发方式，可以降低开发的复杂性。REST从资源的角度来观察整个网络，分布在各处的资源由URI确定，而客户端的应用通过URI来获取资源的表征。

REST具体技术实现:
Asp.Net WebAPI

REST两个基本概念

1.资源（Resource）：将信息抽象为资源，任何能够命名的信息（包括数据和功能）都能作为一个资源，一张图片，一个其他资源的集合等。在REST中，资源又叫做状态，因为它跟随时间的变化。
2.表述（Representation）： REST通过URI来获得资源的表述并对资源执行动作，并在组件间传递该表述。

什么是表述化状态转移？在REST中，资源就是状态，互联网就是一个巨大的状态机：每个网页是其一个状态；Url是状态的表述；REST应用通过点击超链接，从一个状态迁移到下一个状态的状态转移过程，就叫转移。

例如：Bing搜索结果的分页列表，url如下：
第一页:http://www.bing.cn/search?q=REST&hl=zh-CN&newwindow=1&start=0&sa=N

第二页:http://www.bing.cn/search?q=REST&hl=zh-CN&newwindow=1&start=10&sa=N

在Bing中，把搜索结果的每一页视为资源（状态），并通过url来表示(这就是表述)，同一搜索关键字的不同分页通过start参数来进行区分。当你从第一页点击第二页的链接时，只是从一个状态跳到了下一个状态而已(这就是转移)；

REST风格架构的主要约束条件

客户-服务器：分离关注点，将用户接口（如用户界面）和数据存储分离，如果接口不变，组件可独立进化。

无状态：从客户端道服务器的每个请求必须包含理解该请求所必需的所有信息，不能利用任何存储在服务器上的上下文。提高了系统的可扩展性，其优点有三：可见性，监视系统不必为了确定一个请求的性质而去查看请求之外的多个请求；可靠性，减轻了从局部故障恢复的任务量，可以快速定位；可伸缩性，不必在多个请求之 间保存状态，允许服务器快速释放资源，并且服务器不必跨请求管理资源。缺点是，由于不能将状态保存在服务器上的共享上下文中，增加了请求中发送的重复数 据，降低网络性能，因此有了约束三。

缓存：请求响应中的数据显示或隐式的标记为可缓存的或不可缓存的。缓存可以为以后相同的请求重用这个响应的数据。但是缓存管理不好，会降低可靠性，导致缓存中陈旧的数据与直接访问服务器得到的数据差别很大。

统一接口：组件之间要有统一的接口，是REST风格架构区别其他风格架构的核心特征。REST由四个接口约束定义：资源的识别，Web-Based系统中资源由URI表示，数据库存储系统中资源可以是XML，JSON等；通过表述对资源执行的动作：表述中包含操作该资源的信息，如增删改查，映射到HTTP协议的GET，POST，PUT，DELETE方法；自描述的消息：消息中包含如何处理该消息的信息，如由哪个WebAPI/Sevlet处理，响应中包含可不可以被缓存等信息；作为应用状态引擎的超媒体。

REST基本设计原则

原则一： 使用HTTP的方法进行资源访问
使用HTTP POST方法去创建资源，使用GET方法去读取资源，使用PUT 方法去更新资源，使用DELETE方法去删除资源。

原则二： 使用无状态/无会话的服务设计
很长时间以来，人们采用有状态的服务设计从而在客户端与服务端的多次交互中维护一定的上下文。
然而，有状态的设计使得程序很难随着工作负载的增加而进行伸缩。比如某个服务实例拥有10000个会话的状态，则通常很难通过增加服务实例来分担其工作负载：工作负载被锁定了！ 反之，如果程序被设计成一个无状态的，则可以自由增加服务实例，并且在这些实例之间平衡负载，从而使得服务具有较好的伸缩性，这在大规模分布式系统中尤其重要！！

原则三： 用目录结构风格的URL设计来表示资源
用清晰的URL路径表示资源可以使客户端更容易理解和操作资源。URL可以被看作是一种自我解释的接口，不需要太多解释就可以让人明白该URL指向的是什么资源以及如何获得相关的资源。

原则四： 使用XML或JSON来传输数据
服务和请求的消息数据中包含了对于资源的属性的描述，服务应该采取结构良好并且易于阅读的方式来描述资源。XML、JSON都是结构良好的语言，并适于阅读。JSON比XML更加简洁。

REST安全性

REST/HTTP网络服务直接暴露在客户端面前，如何确保服务的安全?

一：REST/HTTP网络服务的信息包可以被防火墙理解和控制。你可以按照操作和链接进行过滤信息包，如你可以规定从外部来的只能读取（GET操作）自己服务器的资源。这样对于系统管理员而言使得软件管理更为简单。

二：REST的安全性还可以利用传输安全协议SSL/TLS、 HTTP基本认证和摘要式认证。

    HTTP基本认证优点是逻辑简单明了、设置简单。缺点显而易见，即使是BASE64后也是可见的明文，很容易被破解、非法利用。还有就是HTTP是无状态的，同一客户端每次都需要验证。对Http认证的不安全的缺点来说，可以启用HTTPS(SSL/TLS)认证作为补充。

    摘要认证（digest authentication）

优点是摘要验证很好地解决了使用基本验证所担心的安全性问题。
但是永远没有绝对的安全，当用户使用字典进行穷举破解时，还是会存在一些被破解的隐患。

三：还可以利用像基于信息的Web Services Security作为安全认证的补充方案。

四：用第三方开源的OpenID和Oauth类库作为安全认证方案的选择。