REST原则
REST（Representational State Transfer 表现层状态转化）即通过客户端/服务器模式，使用URL定位资源，使用HTTP协议对资源进行增删改查操作。
HTTP协议中的四种操作
- get ——获取资源
- post ——新建资源（也可以用于更新资源）
- put ——更新资源
- delete ——删除资源
资源 —— 网络上的一个具体信息
"表现层"（Representation）—— 资源具体呈现出来的形式，如文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现。
HTTP协议，是一个无状态协议，所有的状态都保存在服务器端
客户端想要操作服务器，只能使用HTTP协议让服务器端发生"状态转化"（State Transfer），这种转化是建立在表现层之上的，所以就是"表现层状态转化"。
get —— 小明在浏览器地址栏中输入 http://www.youtube.com/kobehighlight ，客户端（小明的电脑）便通过互联网找到http://www.youtube.com的服务器，然后服务器根据kobehighlight在数据库里找到了科比的视频, 并把视频数据通过互联网传回给了小明的客户端。
post——小明通过浏览器剪掉科比视频中广告的部分，点击”提交“，服务器接到这个请求之后把修改后的视频保存到数据库中，并告诉小明修改已保存。
RESTful架构
符合REST原则的架构，即RESTful架构
- 每一个URI代表一种资源；
- 客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"
RESTful API（REST风格的网络接口）的设计风格
- URL中只使用名词来指定资源，原则上不使用动词，且推荐用复数
- 使用 - 而不是使用 _ 做URL路径中字符串连接
- url中大小写不敏感，不要出现大写字母
- 用HTTP协议里的动词来实现资源的添加，修改，删除等操作
- 使用JSON格式传输数据（不使用XML）
- 用 HTTP Status Code传递Server的状态信息，在REST中都有特定的意义。比如最常用的 200 表示成功，500 表示Server内部错误等。
错误的api设计范例：
http://api.qc.com/v1/deleteFriend —— 使用了动词
RESTful API 与 非RESTful API的对比
- 非RESTful API，在url中描述行为 —— /get_user?id=3
- RESTful API，行为定义在HTTP协议请求头的请求方法中，url中只使用名词，不使用动词 —— GET方法 /user/3
为什么要用RESTful架构？
因为RESTful架构有以下优点：
1. 客户端服务器分离
提高用户界面的便携性（操作简单
通过简化服务器提高可伸缩性（高性能，低成本）
允许组件分别优化（可以让服务端和客户端分别进行改进和优化）
2. 无状态（Stateless）
从客户端的每个请求要包含服务器所需要的所有信息
提高可见性（可以单独考虑每个请求）
提高了可靠性（更容易从局部故障中修复）
提高可扩展性（降低了服务器资源使用）
3. 缓存（Cachable）
服务器返回信息必须被标记是否可以缓存，如果缓存，客户端可能会重用之前的信息发送请求。
利于减少交互次数，减少交互的平均延迟
4. 分层系统（Layered System）
系统组件不需要知道与他交流组件之外的事情。封装服务，引入中间层。
优点：
- 限制了系统的复杂性
- 提高可扩展性
5. 统一接口（Uniform Interface）
优点：
- 提高交互的可见性
- 鼓励单独改善组件
6. 支持按需代码（Code-On-Demand 可选）
提高可扩展性
