我对REST的理解

1:rest的由来
REST即表述性状态传递（英文：Representational State Transfer，简称REST）

通俗点说：资源在网络中以某种表现形式进行状态转移。

源于REST之父 Roy Thomas Fielding 2000年的一篇博士论文。
Fielding是一个非常重要的人，他是HTTP协议（1.0版和1.1版）的主要设计者、Apache服务器软件的作者之一、Apache基金会的第一任主席。
所以，他的这篇论文一经发表，就引起了关注，并且立即对互联网开发产生了深远的影响。
翻译论文一段：”我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。”

论文地址：
Architectural Styles and the Design of Network-based Software Architectures
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

REST章节：
Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST)
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

REST产生的背景？
大家都知道”古代”网页都是前端后端融在一起的，比如之前的PHP，JSP等。在之前的桌面时代问题不大，
但是近年来移动互联网的发展，各种类型的Client层出不穷，RESTful可以通过一套统一的接口为 Web，iOS和Android提供服务。
另外对于广大平台来说，比如Facebook platform，微博开放平台，微信公共平台等，它们不需要有显式的前端，只需要一套提供服务的接口，
于是RESTful更是它们最好的选择。

2:细说Rest(Representational State Transfer）
REST 一种软件架构风格，设计风格而不是标准，只是提供了一组设计原则和约束条件。
满足这些约束条件和原则的应用程序或设计就是 RESTful。

• Representational
  “表现层”省略了主语。其实指的是”资源”（Resources）的”表现层”。
  “资源”，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。
  你可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源
  的地址或独一无二的识别符。

“资源”是一种信息实体，它可以有多种外在表现形式。我们把”资源”具体呈现出来的形式，叫做它的”表现层”（Representation）。
比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现。

• State Transfer
  比如资源的内容和格式都可以看做状态。
  如果客户端想要操作服务器，必须通过某种手段，让服务器端发生”状态转化”（State Transfer）。而这种转化是建立在表现层之上的，
  所以就是”表现层状态转化”。

客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。
它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。

3:REST架构风格的架构约束：

(1)客户-服务器（Client-Server）
通信只能由客户端单方面发起，表现为请求-响应的形式。

(2)无状态（Stateless）
通信的会话状态（Session State）应该全部由客户端负责维护。

(3)缓存（Cache）
响应内容可以在通信链的某处被缓存，以改善网络效率。

(4)统一接口（Uniform Interface）
通信链的组件之间通过统一的接口相互通信，以提高交互的可见性。

(5)分层系统（Layered System）
通过限制组件的行为（即，每个组件只能“看到”与其交互的紧邻层），将架构分解为若干等级的层。

(6)按需代码（Code-On-Demand，可选）
支持通过下载并执行一些代码（例如Java Applet、Flash或JavaScript），对客户端的功能进行扩展。

4:RestFul架构的优点：
结构清晰、符合标准、易于理解、扩展方便。
使异构系统间的通信变得简单
松耦合
易于测试：
（1）浏览器即可作为客户端,还可以借助火狐的插件RestClient。
（2）可以使用Apache的Jemeter。
（3）使用 curl命令行工具

RESTful 的设计方式降低了资源对象设计的自由度，本来你要同时设计对象的状态数据和关联的行为，不太好控制。
而 REST 把 url 里的动词都去掉了，资源对象只剩下有限的几种行为，这样不同的人更容易设计出差不多的东西，
别人看你设计的东西，需要的解释也更少。

简单性
采用REST架构风格，对于开发、测试、运维人员来说，都会更简单。可以充分利用大量HTTP服务器端和客户端开发库、Web功能测试/性能测试工具、HTTP
缓存、HTTP代理服务器、防火墙。这些开发库和基础设施早已成为了日常用品，不需要什么火箭科技（例如神奇昂贵的应用服务器、中间件）就能解决大多数可
伸缩性方面的问题。

可伸缩性
充分利用好通信链各个位置的HTTP缓存组件，可以带来更好的可伸缩性。其实很多时候，在Web前端做性能优化，产生的效果不亚于仅仅在服务器端做性能优化，
但是HTTP协议层面的缓存常常被一些资深的架构师完全忽略掉。

松耦合
统一接口+超文本驱动，带来了最大限度的松耦合。允许服务器端和客户端程序在很大范围内，相对独立地进化。对于设计面向企业内网的API来说，松耦合并不
是一个很重要的设计关注点。但是对于设计面向互联网的API来说，松耦合变成了一个必选项，不仅在设计时应该关注，而且应该放在最优先位置。

5：REST与Jersey和JAX-RS的关系
Rest是一种架构风格。
Jersey是对JAX-RS的一种实现。
JAX-RS（Java API for RESTful Web Services）是一套用java实现REST服务的规范

6:URL设计
糟糕的设计：
/getProducts
/createProducts
/getProducts?proId=4
/updayeProduct?proId=4
/deleteProduct?proId=4

优雅的设计
GET /products
POST /products
GET /products/4
PUT /products/4
DELETE /products/4

注意什么？
（1）：URI使用名词而不是动词，且推荐用复数。

（2）：一个URI标识一个资源，但是一个资源可以被多个URI标识。

（3）：资源也是有层次的，这个层次应该在URI上充分的体现出来。

GET /cars/711/drivers/ 返回 car 711的所有司机

GET /cars/711/drivers/4 返回 car 711的4号司机

（4）：需要有一个URI定义的文档，以备以后的查询和维护。

（5）：合理使用http状态码

（6）：规范返回结果格式
{
errorCode: “401”,
errorMsg: “Unauthorized”
data :data

}
（7）:服务器返回的数据格式，应该尽量使用JSON，避免使用XML。

总之：
看URL就知道要什么
看Http method就知道要干什么
和Http status code就知道结果如何

7：如何单元测试
（1）：浏览器地址栏（GET）
（2）:火狐的RestClient
（3）:Jmeter
（4）:Curl命令行工具

参考文档：
http://www.ruanyifeng.com/blog/2011/09/restful.html
http://blog.csdn.net/column/details/restful.html