RESTful
什么是REST
全拼：Representational State Transfer，中文直译就是，要理解RESTful，首先得知道什么是REST。
REST其实是一组架构约束条件和原则，所以，它首先是需要在符合架构原理的前提下的一组原则，再者，其以网络为基础，所以其充分利用了web的约束条件与原则，其本身就受Web技术的影响很深。
那么RESTful呢？一个架构如果符合REST的约束条件和原则，我们就称它为RESTful架构
理论上REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例。所以这里描述的REST也是通过HTTP实现的REST
那什么是REST原则与约束
一般都会有5个关键的概念：
资源与URI
资源，这里涉及了REST的第一个关键词R(Representational)。任何事物（具体或抽象都可），只要有被引用到的必要，它就是一个资源。
比如：
- 电话号码
- 用户套餐
- 物品价值
要让一个资源可以被识别，需要有个唯一标识，在Web中这个唯一标识就是URI(Uniform Resource Identifier)。
URI既可以看成是资源的地址，也可以看成是资源的名称。如果某些信息没有使用URI来表示，那它就不能算是一个资源， 只能算是资源的一些信息而已。URI的设计应该遵循可寻址性原则，具有自描述性，需要在形式上给人以直觉上的关联，这里就涉及了URI的设计技巧。
URI设计技巧：
-
使用_或-替换数字，使其具有更好的可读性
-
使用/来表示资源的层级关系
-
使用?用来过滤资源
有开发经验的可能想？后面的应该是参数传递才对，但更好的理解应该是对资源的过滤
-
使用“,或;”表示同级关系
统一资源接口
标准的HTTP的GET，DELETE，PUT和POST；一般默认地对应“查、删、改、增”。另外还有HEAD和OPTIONS。
按照HTTP方法的语义来暴露资源，那么接口将会拥有安全性和幂等性的特性，例如GET和HEAD请求都是安全的， 无论请求多少次，都不会改变服务器状态。而GET、HEAD、PUT和DELETE请求都是幂等的，无论对资源操作多少次， 结果总是一样的，后面的请求并不会产生比第一次更多的影响
资源的表述与多重表述
客户端通过HTTP方法可以获取资源，是吧? 不，确切的说，客户端获取的只是资源的表述而已。资源可以有多种表述形式，如文本资源可以使用json、xml等，图片可以为jpg、png等。而客户端与服务端需要通过一种机制协商资源的表述形式，那就是客户端可以通过Accept头请求一种特定格式的表述，服务端则通过Content-Type告诉客户端资源的表述形式
在http中，content-type一共有3钟：
-
text/*
*可为text/json/xml/html，其中不含任何控件或格式字符
-
multipart/form-data
数据被编码为一条消息，页上的每个控件对应消息中的一个部分
-
application/x-www-form-urlencoded
数据被编码为名称/值对
URL：如果我们把版本号理解成资源的不同表述形式的话，就应该只是用一个URL，并通过Accept头部来区分
资源的链接
当你浏览Web网页时，从一个连接跳到一个页面，再从另一个连接跳到另外一个页面，这其实就是超媒体的概念：把一个个把资源链接起来（这其实是构成动态应用的一种有效方式），类似于页面中各种a标签
无状态通信or状态的转移
注意了，无状态通信——并不是说客户端应用不能有状态，而是指服务端不应该保存客户端状态。
状态应该区分应用状态和资源状态，客户端负责维护应用状态，而服务端维护资源状态。REST要求状态要么被放入资源状态中，要么保存在客户端上；换句话说，服务器端不能保持除了单次请求之外的，任何与其通信的客户端的通信状态。这样做的最直接的理由就是可伸缩性—— 如果服务器需要保持客户端状态，那么大量的客户端交互会严重影响服务器的内存可用空间。服务端不需要在请求间保留应用状态，只有在接受到实际请求的时候，服务端才会关注应用状态。
无状态约束使服务器的变化对客户端是不可见的，因为在两次连续的请求中，客户端并不依赖于同一台服务器。
这种无状态通信原则，使得服务端和中介能够理解独立的请求和响应。
"会话"状态不是作为资源状态保存在服务端的，而是被客户端作为应用状态进行跟踪的。客户端应用状态在服务端提供的超媒体的指引下发生变迁，服务端通过超媒体（其实就是资源的链接）告诉客户端当前状态有哪些后续状态可以进入。这也就是状态的转移过程。
参考：
http://www.runoob.com/w3cnote/restful-architecture.html
http://www.infoq.com/cn/articles/rest-introduction/
