对于RESTFUL架构的一点理解和总结

                                      restful架构----面向资源的架构，表征性状态传输（英文：Representational State Transfer，简称REST）

    

1.资源与URI（采用URI标识资源，统一资源标识符，Uniform Resource Identifier）
   urI既是资源的地址，也是资源的名称
   作为资源标识的URI最好具有“可读性”，因为具有可读性的URI更容易被使用，使用者一看就知道被标识的是何种资源
  *使用/来表示资源的层级关系
  *使用？来过滤资源，、users?id=1，ID为1的用户
  *用，； ... 来表示同级的资源
  
2.使用标准的HTTP方法作为统一的资源接口(get,options,head,post,put,delete,patch,)
   因为URI表示资源的名称，而不是对资源的操作，操作使用标准的HTTP方法作为接口
   *get在实现对数据的获取
   *post是做添加，请求者一般不能确定标识添加资源最终采用的URI
   *PUT提供的资源不存在，则做添加操作，否则做修改。（标识添加资源的URI是可以由请求者控制的）
   *delete,删除
 *安全性与幂等性
  安全性：是否会到致服务端资源的变化
   GET、HEAD和OPTIONS均被认为是安全的方法，其它4个HTTP方法，由于它们会导致服务端资源的变化，所以被认为是不安全的方法。
  幂等性：幂等性决定了第二个或者多ge相同请求是否有效。
   GET、HEAD和OPTIONS）均是幂等方法，POST，由于它总是进行添加操作非幂等的方法。PUT请求，只有在对应资源不存在的情况下服务器才会进行添加操作，否则只作修改操作，所以它也是幂等方法
 *用 HTTP Status Code传递Server的状态信息。比如最常用的 200 表示成功，500 表示Server内部错误等。

3.资源的表述
  如：HTML,XML,JSON等都是资源的表述形式
  客户端获取的只是资源的表述，而不是资源的本身。（我的理解就是只是资源的一个URL，时间等能够唯一表示他的，而不是获得资源的二进制流）
  通过HTTP协议的内容协商，来达成资源表述形式的统一。
  *客户端利用的accept头请求 如：Accept: application/json
  *服务端用Content-Type返回表述形式，Content-Type: application/json
如：
{
    "id" : 1,
    "body" : "My first blog post",
    "postdate" : "2015-05-30T21:41:12.650Z",
    "links" : [
        {
            "rel" : "self",
            "href" : http://blog.example.com/posts/1,
            "method" : "GET"
        }
    ] 
}
  
4.资源的链接
  rest不仅仅是对资源的增删改查。
  核心概念：“超媒体即应用状态引擎（hypermedia as the engine of application state）
  REST定位为“分布式超媒体应用，使用超媒体（hypermedia）作为应用状态引擎： 
  如何使用超媒体来增强资源的连通性
  超文本驱动这个理念变成了一个缩写词HATEOAS

5.状态的转移
  无状态通信原则，指服务端不应该保存客户端状态。
  状态应该区分应用状态和资源状态，客户端负责维护应用状态，而服务端维护资源状态：服务端不需要在请求间保留应用状态，只有在接受到实际请求
候，服务端才会关注应用状态。 这种无状态通信原则，使得服务端和中介能够理解独立的请求和响应。 在多次请求中，同一客户端也不再需要依赖于同一服务器，方便实现高可扩展和高可用性的服务端。
  基于cookie session的回话管理是违反了无状态的原则
  客户端应用状态在服务端提供的超媒体的指引下发生变迁。服务端通过超媒体告诉客户端当前状态有哪些后续状态可以进入


解放思想
 Web端不再用之前典型的PHP或JSP架构，而是改为前段渲染和附带处理简单的商务逻辑。
 Web端和Server只使用上述定义的API来传递数据和改变数据状态。
 一般来说restful风格的设计都是以api + json+ajax的方式来交互数据的