REST Web 服务（一）----REST 介绍
1. 什么是REST？
REST 定义了一组体系架构原则，您可以根据这些原则设计以系统资源为中心的 Web 服务，包括使用不同语言编写的客户端如何通过 HTTP 处理和传输资源状态。
2. REST的架构原则？
其具体实现应该遵循四个基本设计原则：
1)显式地使用 HTTP 方法。
2)无状态通信。
3)公开目录结构式的 URI。
4)传输 XML、JavaScript Object Notation (JSON)，或同时传输这两者。
关于REST原则的详细内容见：基于 REST 的 Web 服务：基础
3. REST特点
REST (REpresentational State Transfort) 形式上应该表述为客户端通过申请资源来实现状态的转换，在这个角度系统可以看成一台虚拟的状态机。REST应该满足这样的特点：
1)客户端和服务器结构；
2)连接协议具有无状态性；
无状态性是在客户－服务器约束的基础上添加的又一层规范。他要求通信必须在本质上是无状态的，即从客户到服务器的每个request都必须包含理解该 request所必须的所有信息。这个规范改善了系统的可见性（无状态性使得客户端和服务器端不必保存对方的详细信息，服务器只需要处理当前 request，而不必了解所有的request历史），可靠性（无状态性减少了服务器从局部错误中恢复的任务量），可伸缩性（无状态性使得服务器端可以 很容易的释放资源，因为服务器端不必在多个request中保存状态）。
3)能够利用Cache机制增进性能；
为了改善无状态性带来的网络的低效性，我们填加了缓存约束。缓存约束允许隐式或显式地标记一个response中的数据，这样就赋予了客户端缓存 response数据的功能，这样就可以为以后的request共用缓存的数据，部分或全部的消除一部分交互，增加了网络的效率。
4)层次化的系统；
分层系统规则的加入提高了各种层次之间的独立性，为整个系统的复杂性设置了边界，通过封装遗留的服务，使新的服务器免受遗留客户端的影响，这也就提高了系统的可伸缩性。
5)按需代码。
REST允许对客户端功能进行扩展。比如，通过下载并执行applet或脚本形式的代码，来扩展客户端功能。但这在改善系统可扩展性的同时，也降低了可见性。所以它只是REST的一个可选的约束。
4. REST与SOAP的区别
1）SOAP WS支持既远程过程调用（例如，RPC）又支持消息中间件（MOM）方式进行应用集成。而Restful Web Service仅支持RPC集成方式。
2）SOAP WS是传输协议无关的。它支持多种协议，比如，HTTP(S)、 Messaging、TCP、UDP SMTP等等。而REST是协议相关的，只支持HTTP或者HTTPS协议。
3）SOAP WS仅允许使用XML数据格式。定义的操作通过POST请求发送。其重点是通过操作名来获取服务，并将应用逻辑封装为服务。而REST方式则允许多种数据格式，例如，XML、JSON、文本、HTML等等。而且由于REST方式采用标准GET、PUT、PSOT和DELETE 方法，因此所有的浏览器都可以支持。其重点是通过资源名来获取服务，并将数据封装为服务。AJAX支持REST方式，它可以使用 XMLHttpRequest对象。无状态CRUD操作（创建、读、更新和删除）更加适合这种方式。
GET – represent()
POST – acceptRepresention()
PUT – storeRepresention()
DELETE – removeRepresention()
4）无法缓存SOAP方式读取的内容。而REST方式的则可以，而且性能和可扩展性都更好一些。 SOAP WS支持SSL和WS-security，针对企业级应用可以有更多的安全保障，例如按需提升安全指数、通过第三方来保证身份认证信息的安全性、除了点到点SSL（point to point SSL）之外，更针对消息的不同部分来提供不同的保密算法等等。而REST只支持点到点SSL。而且无论是不是敏感消息，SSL都会加密整条消息。
5）SOAP对于基于ACID的短寿命事务管理以及基于补偿事务管理的长寿命事务有深入的支持。同时，SOAP也支持分布式事务（译者：在一个分布式环境中涉及到多个资源管理器的事务）的两阶段提交（two-phase commit）方式。而REST由于基于HTTP协议，因此对于事务处理既不兼容ACID方式也不提供分布式事务的两阶段提交方式。
6）即便是要通过SOAP的第三方程序，SOAP通过内置的重试逻辑也可以提供端到端可靠性。REST没有一个标准的消息系统，因而寄希望于客户通过重连去解决通信失败问题。
5. RESTful架构有一些典型的设计误区
最常见的一种设计错误，就是URI包含动词。因为"资源"表示一种实体，所以应该是名词，URI不应该有动词，动词应该放在HTTP协议中。 举例来说，某个URI是/posts/show/1，其中show是动词，这个URI就设计错了，正确的写法应该是/posts/1，然后用GET方法表示show。 如果某些动作是HTTP动词表示不了的，你就应该把动作做成一种资源。比如网上汇款，从账户1向账户2汇款500元，错误的URI是：
POST /accounts/1/transfer/500/to/2
正确的写法是把动词transfer改成名词transaction，资源不能是动词，但是可以是一种服务：
POST /transaction HTTP/1.1
Host: 127.0.0.1
from=1&to=2&amount=500.00
另一个设计误区，就是在URI中加入版本号：
http://www.example.com/app/1.0/foo
http://www.example.com/app/1.1/foo
http://www.example.com/app/2.0/foo
因为不同的版本，可以理解成同一种资源的不同表现形式，所以应该采用同一个URI。版本号可以在HTTP请求头信息的Accept字段中进行区分（参见Versioning REST Services）：
Accept: vnd.example-com.foo+json; version=1.0
Accept: vnd.example-com.foo+json; version=1.1
Accept: vnd.example-com.foo+json; version=2.0
6. RESTful API设计原则？
1）每个实体对象仅需要两个URL
/books # for Collections
/books/2 # for Single Object
每个对象仅需要两个url，第一个是获取对象的集合，第二个是获取单个对象
2）使用名词代替动词
/books/2 # Good :)
/getBook?id=2 # Bad :(
3）正确使用HTTP方法
GET # Read
POST # Create
PUT # Update
DELETE # Delete
4）对象间的关联关系
/books/2/author # book author
/author/1/books # author's books
5）数据分页
/books?start=10&count=20 # return the books from 10 to 30
6）查询条件
/books?order=hot # return the books order by hot
7）返回需要的参数
/books/2?fields=author,isbn,price # only return the book's author, isbn and price
8）错误处理
依靠status code来给程序标识错误，常见的status code如下：
200 - OK # GET success
201 - CREATED # POST success
202 - ACCEPTED # PUT success
400 - BAD REQUEST # Wrong path or unsupported parameters
401 - UNAUTHORIZED # Need Authorize
403 - FORBIDDEN # forbidden to access
404 - NOT FOUND # Resource not exists
500 - INTERNAL ERROR # Server error
具体的错误信息和错误代码（自定义的错误代码）也要返回：
{"code": 1000, "message": "missing_args", "request": "GET /books/2"}
