1:rest的由来
REST即表述性状态传递（英文：Representational State Transfer，简称REST）
通俗点说：资源在网络中以某种表现形式进行状态转移。
源于REST之父 Roy Thomas Fielding 2000年的一篇博士论文。
Fielding是一个非常重要的人。他是HTTP协议（1.0版和1.1版）的主要设计者、Apacheserver软件的作者之中的一个、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
比方资源的内容和格式都能够看做状态。
假设client想要操作server，必须通过某种手段。让server端发生”状态转化”（State Transfer）。而这样的转化是建立在表现层之上的。
所以就是”表现层状态转化”。
client用到的手段，仅仅能是HTTP协议。详细来说。就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。
它们分别相应四种基本操作：GET用来获取资源，POST用来新建资源（也能够用于更新资源）。PUT用来更新资源。DELETE用来删除资源。
3:REST架构风格的架构约束：
(1)客户-server（Client-Server）
通信仅仅能由client单方面发起，表现为请求-响应的形式。
(2)无状态（Stateless）
通信的会话状态（Session State）应该所有由client负责维护。
(3)缓存（Cache）
响应内容能够在通信链的某处被缓存，以改善网络效率。
(4)统一接口（Uniform Interface）
通信链的组件之间通过统一的接口相互通信。以提高交互的可见性。
(5)分层系统（Layered System）
通过限制组件的行为（即，每个组件仅仅能“看到”与其交互的紧邻层），将架构分解为若干等级的层。
(6)按需代码（Code-On-Demand。可选）
支持通过下载并运行一些代码（比如Java Applet、Flash或JavaScript）。对client的功能进行扩展。
4:RestFul架构的长处：
结构清晰、符合标准、易于理解、扩展方便。
使异构系统间的通信变得简单
松耦合
易于測试：
（1）浏览器就可以作为client,还能够借助火狐的插件RestClient。
（2）能够使用Apache的Jemeter。
（3）使用 curl命令行工具
RESTful 的设计方式减少了资源对象设计的自由度。本来你要同一时候设计对象的状态数据和关联的行为，不太好控制。
而 REST 把 url 里的动词都去掉了，资源对象仅仅剩下有限的几种行为，这样不同的人更easy设计出差点儿相同的东西。
别人看你设计的东西，须要的解释也更少。
简单性
採用REST架构风格，对于开发、測试、运维人员来说。都会更简单。能够充分利用大量HTTPserver端和client开发库、Web功能測试/性能測试工具、HTTP
缓存、HTTP代理server、防火墙。这些开发库和基础设施早已成为了日经常使用品，不须要什么火箭科技（比如奇妙昂贵的应用server、中间件）就能解决大多数可
伸缩性方面的问题。
可伸缩性
充分利用好通信链各个位置的HTTP缓存组件。能够带来更好的可伸缩性。事实上非常多时候，在Web前端做性能优化，产生的效果不亚于仅仅在server端做性能优化，
可是HTTP协议层面的缓存经常被一些资深的架构师全然忽略掉。
松耦合
统一接口+超文本驱动。带来了最大限度的松耦合。
同意server端和client程序在非常大范围内。相对独立地进化。对于设计面向企业内网的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）:server返回的数据格式，应该尽量使用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
———————————————————————————————————————
我开通了微信订阅号“i小窝”，关注就可以第一时间看到我的原创文章以及我推荐的精彩文章：
