restful概念理解

一、概念

1.    rest概念：    REST（representational state transfer）表现层状态转移化，省略了主语。"表现层"其实指的是"资源" （Resources）的" 表现层"。

 ①资源：所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。你可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。所谓"上网"，就是与互联网上一系列的"资源"互动，调用它的URI。

②表现层：  "资源"是一种信息实体，它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式，叫做它的"表现层"（Representation）。
比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现。

URI只代表资源的实体，不代表它的形式。严格地说，有些网址最后的".html"后缀名是不必要的，因为这个后缀名表示格式，属于"表现层"范畴，而URI应该只代表"资源"的位置。它的具体表现形式，应该在HTTP请求的头信息中用 Accept和Content-Type字段指定，这两个字段才是对"表现层"的描述。

③状态转移化：访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。

互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。

客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。

④综合上面的解释，我们总结一下什么是RESTful架构：

　　（1）每一个URI代表一种资源；

　　（2）客户端和服务器之间，传递这种资源的某种表现层；

　　（3）客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。

二、简介

REST :  它是一种网络化超媒体应用的架构风格，它主要是用于构建轻量级的、可维护的、可伸缩的 Web 服务。基于 REST 的服务被称为 RESTful 服务。  REST 不依赖于任何协议，但是几乎每个 RESTful 服务使用 HTTP 作为底层协议。REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。

强调三点：
（一）  首先REST只是一种风格，不是一种标准
（二）  REST是以资源为中心的
（三）  REST充分利用或者说极端依赖HTTP协议     

三、特点

RESTful 服务特点：服务的目的是提供一个窗口给客户端以便客户端能访问这些资源。服务架构师和开发人员想要这些服务变得易于实现、维护、扩展、伸缩。RESTful 架构允许这些，甚至更多。一般来说

REST架构风格最重要的架构约束有6个：

• 客户-服务器（Client-Server）

通信只能由客户端单方面发起，表现为请求-响应的形式。

• 无状态（Stateless）

通信的会话状态（Session State）应该全部由客户端负责维护。

• 缓存（Cache）

响应内容可以在通信链的某处被缓存，以改善网络效率。

• 统一接口（Uniform Interface）

通信链的组件之间通过统一的接口相互通信，以提高交互的可见性。

• 分层系统（Layered System）

通过限制组件的行为（即，每个组件只能“看到”与其交互的紧邻层），将架构分解为若干等级的层。

• 按需代码（Code-On-Demand，可选）

支持通过下载并执行一些代码（例如Java Applet、Flash或JavaScript），对客户端的功能进行扩展。

四、统一资源接口

RESTful架构应该遵循统一接口原则，统一接口包含了一组受限的预定义的操作，不论什么样的资源，都是通过使用相同的接口进行资源的访问。接口应该使用标准的HTTP方法如GET，PUT和POST，并遵循这些方法的语义。

　　如果按照HTTP方法的语义来暴露资源，那么接口将会拥有安全性和幂等性的特性，例如GET和HEAD请求都是安全的， 无论请求多少次，都不会改变服务器状态。而GET、HEAD、PUT和DELETE请求都是幂等的，无论对资源操作多少次， 结果总是一样的，后面的请求并不会产生比第一次更多的影响。

下面列出了GET，DELETE，PUT和POST的典型用法:：

GET
    SELECT，如果这个业务操作不会改变服务器的数据，那么就可以将它抽象成GET方法，但也不绝对，比如很多网站提供了文件下载，按理说下载应该是不会改变服务器数据的，所以用GET，但很多时候服务器还提供了下载计数，你说这算不算改变了服务器的数据？——这种情况一般不算，所以依然用GET。下面是GET方法的举例：
    获取所有员工列表
    按条件分页查询某些员工信息
    获取一个员工的信息
    下载一个文件
    获取当前输入的商品的价格

PUT
    UPDATE一条记录就抽象成PUT方法，那这个动作是不是也会用得很多呢？这个比你想像中的少得多，为什么？因为大量的修改记录的动作都不只是一个简单的UPDATE动作，比如用户要撤销一个订单，这个操作表面上看起来是修改一条订单记录的状态为“撤销”，但实际上比这个要复杂得多，我们的订货是有流程的，用户撤销一个订单其实只是向我们的服务器提出了一个撤销订单的请求，让这个订单转入了撤销流程，而不是简单地修改订单记录的状态，这里面有一连串的动作，比如：等待管理员确认，更新应收款信息，将已出库的货物重新入库，写操作日志，发送系统通知等等，所以这个动作应该是POST，而不是PUT，大多数涉及业务流程的东西都是POST，这个我后面会再提到，而PUT则用于简单的，不涉及业务流程的数据库单条记录UPDATE，例如：
    用户修改自己的个人信息（假设这个修改动作不 需要审批）
    用户编辑了一张暂存（未转入执行流程）的订单

POST
    表面上看起来对应到数据库的一次INSERT，但实际上对比PUT，POST的使用是广泛很多的，可以说大多数业务操作都会被抽象成POST方法，例如：
    新增一个用户
    提交一个订单
    撤销一个订单
    付款
    给员工发放工资
    提交一个基础资料的修改申请（需要审批）
    激活一个产品
    驳回一个员工的申请

DELETE
    对应SQL语句的DELETE，表示删除一个对象，是不是应该使用也很多呢？其实跟PUT一样，使用得比你想像的少，因为大多数时候，我们的数据库所执行的“删除”都不是简单的DELETE，甚至大多数对象，我们都不会提供直接的删除，例如用户，为了保证数据的完整性，我们在数据库中使用了许多的外键约束，要直接DELETE一条用户记录是不会成功的，我们只能“停用”一个用户，表示此用户不再生效。当然了，话不是那么绝对，如果这是个刚刚增加的用户并且没有在其它表中引用到它，那么确实可以直接把它DELETE掉，这种情况出现在管理员刚刚添加了一个用户，但发现用户名输错了，而用户名却是无法修改的，管理员只能尝试删除这个用户然后重新添加，或者“停用”掉这个错误的用户，只是这么一来会产生一条完全没意义的用户记录。DELETE用于你认为需要提供DELETE方法的场合（很多时候其实不需要，这取决于你的设计），例如：
    删除一个用户（很可能执行失败）
    删除一条暂存的订单（此订单尚未转入处理流程）
    删除一条系统消息

四、影响

            REST 定义了一组体系架构原则，大家可以根据这些，包括使用不同语言编写的客户端如何通过

            HTTP 处 理和传输资源状态。所以在事实上，REST 对 Web的影响非常大，由于其使用相当方便，

            已经普遍地取代了基于 SOAP 和 WSDL 的接口设计。