参考借鉴：http://www.cnblogs.com/loveis715/p/4669091.html
一、定义
REST其实是一种组织Web服务的架构，而并不是我们想象的那样是实现Web服务的一种新的技术，更没有要求一定要使用HTTP。其目标是为了创建具有良好扩展性的分布式系统。与目前常见的web设计架构区别点在于，REST是以资源为中心，而常规web架构是以执行了什么任务为中心。
二、五大约束
1、使用客户/服务器模型。客户和服务器之间通过一个统一的接口来互相通讯。
2、层次化的系统。在一个REST系统中，客户端并不会固定地与一个服务器打交道。
3、无状态。在一个REST系统中，服务端并不会保存有关客户的任何状态。也就是说，客户端自身负责用户状态的维持，并在每次发送请求时都需要提供足够的信息。
4、可缓存。REST系统需要能够恰当地缓存请求，以尽量减少服务端和客户端之间的信息传输，以提高性能。
5、统一的接口。一个REST系统需要使用一个统一的接口来完成子系统之间以及服务与用户之间的交互。这使得REST系统中的各个子系统可以独自完成演化。（是REST服务设计的核心所在）
三、统一接口四个子约束
1、每个资源都拥有一个资源标识。每个资源的资源标识可以用来唯一地标明该资源。
2、消息的自描述性。在REST系统中所传递的消息需要能够提供自身如何被处理的足够信息。例如该消息所使用的MIME类型，是否可以被缓存等。
3、资源的自描述性。一个REST系统所返回的资源需要能够描述自身，并提供足够的用于操作该资源的信息，如如何对资源进行添加，删除以及修改等操作。也就是说，一个典型的REST服务不需要额外的文档对如何操作资源进行说明。
4、HATEOAS。即客户只可以通过服务端所返回各结果中所包含的信息来得到下一步操作所需要的信息(客户端仅可以决定资源ID)，如到底是向哪个URL发送请求等。也就是说，一个典型的REST服务不需要额外的文档标示通过哪些URL访问特定类型的资源，而是通过服务端返回的响应来标示到底能在该资源上执行什么样的操作。一个REST服务的客户端也不需要知道任何有关哪里有什么样的资源这种信息。
四、资源操作方式
1、GET 等幂且安全，读取资源
2、DELETE 等幂 ，删除资源
3、POST 不等幂，创建资源，ID由服务端创建
4、PUT 等幂，创建资源和更新整个资源，ID由客户端创建，一般通过GUID和UUID
5、PATCH 等幂，更新部分资源
注：等幂性，是指每次操作结果都一样
五、HTTP Code
参照：Hypermedia ControlsHypermedia Controlshttp://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
100 Continue
101 Switching
102 Processing
103-199 Unassigned
200 OK
201 Created
202 Accepted
203 Non-Authoritative Information
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status
208 Already Reported
209-225 Unassigned
226 IM Used
227-299 Unassigned
300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
306 (Unused)
307 Temporary Redirect
308 Permanent Redirect
309-399 Unassigned
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Payload Too Large
414 URI Too Long
415 Unsupported Media Type
416 Range Not Satisfiable
417 Expectation Failed
418-420 Unassigned
421 Misdirected Request
422 Unprocessable Entity
423 Locked
424 Failed Dependency
425 Unassigned
426 Upgrade Required
427 Unassigned
428 Precondition Required
429 Too Many Requests
430 Unassigned
431 Request Header Fields Too Large
432-450 Unassigned
451 Unavailable For Legal Reasons
452-499 Unassigned
500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates
507 Insufficient Storage
508 Loop Detected
509 Unassigned
510 Not Extended
511 Network Authentication Required
512-599 Unassigned
六、开发注意
对于一个基于HTTP的REST服务而言，软件开发人员需要遵守如下的守则以保持API的后向兼容性（即兼容旧版本）：
1、不能在请求中添加新的必须的参数。
2、不能更改操作资源的动词。
3、不能更改响应的HTTP status。
七、性能优化
接下来我们就来简单地说说基于HTTP的REST服务中的性能问题。在基于HTTP的REST服务中，性能提升主要分为两个方面：REST架构本身在提高性能方面做出的努力，以及基于HTTP协议的优化。
首先要讨论的就是对登陆性能的优化。在前面我们已经介绍过，在一个基于HTTP的REST服务中，每次都将用户的用户名和密码发送到服务端并由服务端验证这些信息是否合法是一个非常消耗资源的流程。因此我们常常需要在登陆服务中使用一个缓存，或者是使用第三方单点登陆（SSO）类库。
除此之外，软件开发人员还可以通过为同一个资源提供不同的表现形式来减少在网络上传输的数据量，从而提高REST服务的性能。
而在集群内部服务之间，我们则可以不再使用JSON，XML等这种用户可以读懂的负载格式，而是使用二进制格式。这样可以大大地减少内部网络所需要传输的数据量。这在内部网络交换数据频繁并且所传输的数据量巨大时较为有效。
接下来就是REST系统的横向扩展。在REST的无状态约束的支持下，我们可以很容易地向REST系统中添加一个新的服务器。
除了这些和REST架构本身相关的性能提升之外，我们还可以在如何更高效地使用HTTP协议上努力。一个最常见的方法就是使用条件请求（Conditional Request）。简单地说，我们可以使用如下的HTTP头来有条件地存取资源：
1、ETag：一个对用户不透明的用来标示资源实例的哈希值
2、Data-Modified：资源被更改的时间
3、If-Modified-Since：根据资源的更改时间有条件地Get资源。这将允许客户端对4、未更改的资源使用本地缓存。
5、If-None-Match：根据ETag的值有条件地Get资源。
6、If-Unmodified-Since：根据资源的更改时间有条件地Put或Delete资源。
7、If-Match：根据ETag的值有条件地Put或Delete资源。
当然，这里所提到的一系列性能优化方案实际上仅仅是比较常见的，与基于HTTP的REST服务关联较大的方案。只是顾虑到过多地陈述和REST关联不大的话题一方面显得比较没有效率，另一方面也是因为通过写另一个系列博客可以将问题陈述得更加清楚，因此在这里我们将不再继续讨论性能相关的话题。
