我对REST的理解

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小窝”，关注就能够第一时间看到个人原创文章以及我推荐的精彩文章：