文章目录
REST简介
REST风格的架构
使用“api”作为上下文
增加一个版本标识
标识资源
确定HTTP Method
确定HTTP Status

REST简介
REST，即Representational State Transfer的缩写，翻译为“表现层状态转化”，如果一个架构符合REST原则，则称其为RESTful架构。

资源（Resources）

REST的名称“表现层状态转化”，表现层指的是“资源”的“表现层”。

所谓“资源”，就是网络上的一个实体，或者说是网络上的一个具体信息，它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实体。可以用一个具体的URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以。

因此URL就成了每个资源的地址或第一无二的标识符。

表现层

“资源”是一种信息实体，可以有多种外在表现形式。将“资源”具体呈现出来的形式称之为“表现层”。比如，文本可以用txt格式表现，也可用HTML格式、XML格式、JSON格式等。
URI只代表资源的实体，不代表它的形式。它的具体表现形式应该在HTTP请求的头信息中用Accept和Content-Type字段指定。

状态转化

访问一个网站。就代表了客户端和服务器的一个互动过程，这个过程中，势必涉及和状态的变化。

HTTP协议是一个无状态互联网通信协议，这意味着所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生“状态转化”。而这种转化是建立在表现层之上的，所以就是“表现层状态转化”。
URI：统一资源标识符
URL：统一资源定位符

REST风格的架构
包括了REST架构中如何标识资源，如何标识操作接口以及操作的版本，如何标识操作的结果等，如：

使用“api”作为web上下文；
增加版本标识；
标识资源；
REST中的HTTP Method；
REST中的HTTP Status；

使用“api”作为上下文
建议使用“api”作为上下文，如：
http://localhost/api
http://api.xxx.com

增加一个版本标识
http://localhost/api/v1.1

标识资源
将资源名称放到URL中，如果资源有层级关系，则放入层级关系：
http://localhost:/api/v1.1/user
//如果用户属于系统管理，则：
http://localhost:/api/v1.1/system/user

确定HTTP Method
在REST中，HTTP Method通常对应以下含义：

POST：代表增加资源；
PUT：代表更改资源，客户端提供完整的资源属性；
GET：代表查询资源；
PATCH：更新资源，客户端提供仅需要更改的资源属性；
DELETE：删除资源；
OPTIONS：用于获取URI所支持的方法，响应信息会在HTTP头中包含一个名为“Alllow”的头，值是所支持的方法，如“GET”、“POST”。


在业务系统中，删除往往不是指物理删除，而是逻辑删除，资源通常仍在数据库中，只是状态设置为删除状态。

确定HTTP Status
服务器向客户端返回HTTP Status以表示操作是否成功，常用的如下：

200，OK，用户请求成功，如查询数据成功返回。
400，错误的请求，如URI匹配上的Controller，但是方法参数匹配错误，就会抛出错误。
404NOT Found，用户发出的请求针对的资源不存在。通常是Controller没有匹配上URI，或者匹配上了Controller方法，但渲染的视图不存在。
405，用来访问本页面的HTTP Method不被允许，比如通过HTTP GET方式访问了一个@PostMapping的Controller方法。
406，表示无法使用请求的内容来响应请求的资源，如请求后缀以html结尾，但同时请求的HTTP头中又包含了Accept:application/json。
500，服务器内部错误，无法完成请求，通常是Controller抛出的错误。

REST（REpresentational State Transfer）是一种设计网络应用时的架构风格，以抽象的“资源（Resource）”为中心，各个模块之间通过转移（Transfer）沟通资源的"表态状态（Representational State）"来实现应用的功能，从而使网络应用得以简易性，扩展性，可靠性等。
RESTful API有助于客户端和服务端的功能分离，服务器完全扮演着一个“资源服务商”的角色。各种不同的客户端都可以通过一致的API与这个“资源服务商”交流，从而与资源进行互动。
REST暴露的是“接口资源”，而不是“接口操作”。
RESTful API（具有REST风格的API）：用URL（资源ID）定位每一个页面（资源），用HTTP动词（GET、HEAD、POST、PUT、PATCH、DELETE）描述操作资源，用响应状态码表示操作结果。但是REST远远不仅是指API的风格，它是一种网络应用的架构风格。


架构风格描述了六个约束。应用于体系结构的这些约束最初由Roy Fielding在他的博士论文中传达，并定义了RESTful的基础样式。


客户端和服务端的分割：REST 构架要求是基于客户端和服务端的。通过一个统一的接口来分开客户端和服务器，使得两者可以独立开发和演化。客户端不关心数据的存储，而服务端不关心用户的交互和会话的状态。这样可以做到客户端的可替换性，和服务端的兼容性。


统一接口（客户端和服务端之间通信的统一规范性）：



所有的通信都是基于资源的,通信的内容都是资源的表征状态；
客户端通过表征状态就可以创建读取修改资源；
所有的通信都是自解释的，每条消息都有足够的信息来告诉对方自己应该被如何解析；
使用超媒体来作为传送的表征状态；服务端往往会在表征状态中加入其他资源链接的方式让客户端可以在下一次通信中获取其他资源。



分层的系统（客户端和服务端直接可以插入很多层）：这样服务端可以被很容易地扩展为负载平衡服务器组来处理安全策略和缓存等相关问题,客户端并不需要了解中间的这些层次的细节。


无状态（服务端是无状态的）：符合REST风格的服务端不应该保存任何用户状态，而是在客户端保存用户会话的状态。这样的好处是明显降低服务器开销，提高快速错误恢复的能力。


可缓存。客户端可以缓存服务器返回的响应结果。服务器可以定义响应结果的缓存设置。


按需代码（服务端给客户端按需提供Code资源）：这是一个可选风格，但是它在很多REST应用中却非常重要，因为它使得不改变客户端就可以扩展客户端的功能。简单的说，这种风格是将逻辑代码也看成是一种资源，可以自由从服务端取得，并到客户端上面执行。比如浏览器从服务端下载一段javascript 代码资源，并执行它来达到用户的某个需求。


以上的6条属性中，除了第6条以外，其它的任意一条不满足的服务就不能被称作REST服务。
RESTful的CRUD
@RequestMapping：通过设置method属性的CRUD，可以将同一个URL映射到不同的HandlerMethod方法上。

@GetMapping、@PostMapping、@PutMapping、@DeleteMapping注解同@RequestMapping注解的method属性设置。
RESTful的URL路径变量
@PathVariable：可以解析出来URL中的模板变量（{id}/{name}）
// URL：http://localhost:8080/ssm/cyb/item/1/zhangwenhui

// Controller层:

@RequestMapping("{id}/{name}")
@ResponseBody
public Item queryItemById(@Pathvariable Integer id,@PathVariable String name){
……
}

【虎.无名】从javaeye上看到三篇文章：

dlee : 主题：关于REST一些最新的业界动态 时间：2007-06-02 关键字: REST 

robbin : 主题：从分布式系统的角度看REST 时间：2007-05-23 

AllenYoung : 主题：关于REST的一点想法，欢迎大家讨论。时间：2007-04-11

1，首先，最重要的是，Sun启动了JSR 311的开发过程：http://www.infoq.com/news/2007/02/jsr-311-java-rest-api 和 JSR
 311: JAX-RS: The Java API for RESTful Web Services 这个JSR的开发还请了目前最成熟的Java REST框架Restlet的作者Jerome Louvel参与到其中，Restlet API很有可能会被JCP采纳作为制定这个新标准的基础。 

孟岩前一段时间告诉我： 我刚刚从美国回来，参加了IBM Impact 07大会，现在IBM已经把REST放在SOA整个的战略框架之中来考虑，因此很快会出现商业的REST支持产品。 

M$前一段时间刚刚发布他们的REST风格的Web服务解决方案Astoria：http://www.infoq.com/cn/news/2007/05/astoria 

Nokia也将REST作为他们服务器端整体架构中的一个重要的部分：http://www.ftponline.com/conferences/virtual/wb20/2006/materials/Development/RemoteControlforWEB20.pdf 此外还有很多公司对REST感兴趣，我的一个在BO（http://www.businessobjects.com/）的朋友说他们现在做的项目已经有一半都是基于REST了，我的另一个在毕博软件的朋友说他们也对REST很感兴趣。 

O'Reilly最近出版了一本关于REST的专著：RESTful Web Services http://www.oreilly.com/catalog/9780596529260/

2，REST最大的特点是什么呢？REST是为通过HTTP协议来进行分布式调用量身定造的架构。传统上，我们开发一个非分布式的软件系统，使用OO进行建模和架构，无往而不利。但是分布式对象却显得不那么有效。对于跨进程的调用，也许我们需要探索更好的面向对象的分布式调用架构。 REST是专门为分布式调用设计的架构，在REST里面，分布式是通过对资源的操作来实现的，不是像EJB那样通过对象的方法调用来实现的。资源是一种抽象的概念，资源被映射到相应的一套URL规则上面了。所以资源只和URL相关，而与具体实现无关，因此REST具有更好的解藕性。在RoR的实现当中，你可以把一些资源直接映射到model对象上面去，也可以不映射到model上面，而完全是由业务逻辑组合的抽象资源。

3，REST提出了一些设计概念和准则：
网络上的所有事物都被抽象为资源（resource）；【REST通过URI暴露资源，而不是通过消息接口暴露服务】
每个资源对应一个唯一的资源标识（resource identifier）； 【虎.无名：id不一定是数字，也可是任意字符串，包括中文。完整的资源id实质是一个URI】
通过通用的连接器接口（generic connector interface）对资源进行操作；【虎.无名：会HTTP就行】
对资源的各种操作不会改变资源标识； 【虎.无名：URL的一致性，便于搜索引擎优化。SEO】
所有的操作都是无状态的（stateless）。 【虎.无名：这点比较难，很多地方需要重构，尤其设计用户登录、权限、会话等部分，要求通过其它方式，每次访问都含有有效登录信息，自动登录。】

REST之所以能够简化开发，是因为其引入的架构约束，比如Rails 1.2中对REST的实现默认把controller中的方法限制在7个：index、show、new、edit、create、update和destory，这实际上就是对CURD的实现。更进一步讲，Rails（也是当今大部分网络应用）使用HTTP作为generic connector interface，HTTP则把对一个url的操作限制在了4个之内：GET、POST、PUT和DELETE。

REST之所以能够提高系统的可伸缩性，是因为它强制所有操作都是stateless的，这样就没有context的约束，如果要做分布式、做集群，就不需要考虑context的问题了。同时，它令系统可以有效地使用pool。REST对性能的另一个提升来自其对client和server任务的分配：server只负责提供resource以及操作resource的服务，而client要根据resource中的data和representation自己做render。这就减少了服务器的开销。

既然REST有这样的好处，那我们应该义无反顾地拥抱它啊！目前一些大牛（像DHH）都已经开始投入到了REST的世界，那我们这些人应该做什么或者说思考写什么你呢？我觉得我们应该思考两个问题：1）如何使用REST；2）REST和MVC的关系。 第一个问题假设REST是我们应该采用的架构，然后讨论如何使用；第二个问题则要说明REST和当前最普遍应用的MVC是什么关系，互补还是取代？


我们先来谈谈第一个问题，如何使用REST。我感觉，REST除了给我们带来了一个崭新的架构以外，还有一个重要的贡献是在开发系统过程中的一种新的思维方式：通过url来设计系统的结构。根据REST，每个url都代表一个resource，而整个系统就是由这些resource组成的。因此，如果url是设计良好的，那么系统的结构就也应该是设计良好的。对于非高手级的开发人员来说，考虑一个系统如何架构总是一个很抽象的问题。敏捷开发所提倡的Test Driven Development，其好处之一（我觉得是最大的好处）就是可以通过testcase直观地设计系统的接口。比如在还没有创建一个class的时候就编写一个testcase，虽然设置不能通过编译，但是testcase中的方法调用可以很好地从class使用者的角度反映出需要的接口，从而为class的设计提供了直观的表现。这与在REST架构中通过url设计系统结构非常类似。虽然我们连一个功能都没有实现，但是我们可以先设计出我们认为合理的url，这些url甚至不能连接到任何page或action，但是它们直观地告诉我们：系统对用户的访问接口就应该是这样。根据这些url，我们可以很方便地设计系统的结构。

让我在这里重申一遍：REST允许我们通过url设计系统，就像Test Driven Development允许我们使用testcase设计class接口一样。OK，既然url有这样的好处，那我们就着重讨论一下如何设计url。网络应用通常都是有hierarchy的，像棵大树。我们通常希望url也能反映出资源的层次性。比如对于一个blog应用：/articles表示所有的文章，/articles/1表示id为1的文章，这都比较直观。遗憾的是，网络应用的资源结构永远不会如此简单。因此人们常常会问这样一个问题：RESTful的url能覆盖所有的用户请求吗？比如，login如何RESTful？search如何RESTful？

从REST的概念上来看，所有可以被抽象为资源的东东都可以使用RESTful的url。因此对于上面的两个问题，如果login和search可以被抽象为资源，那么就可以使用RESTful的url。search比较简单，因为它会返回搜索结果，因此可以被抽象为资源，并且只实现index方法就可以了（只需要显示搜索结果，没有create、destory之类的东西）。然而这里面也有一个问题：search的关键字如何传给server？index方法显然应该使用HTTP GET，这会把关键字加到url后面，当然不符合REST的风格。要解决这个问题，可以把每次search看作一个资源，因此要创建create和index方法，create用来在用户点击“搜索”按钮是通过HTTP
 POST把关键字传给server，然后index则用来显示搜索结果。这样一来，我们还可以记录用户的搜索历史。使用同样的方法，我们也可以对login应用REST，即每次login动作是一个资源。

现在，我们来复杂一些的东东。如何用url表达“category为ruby的article”？一开始可能想到的是/category/ruby/articles，这种想法很直观。但是我觉得里面的category是不需要的，我们可以直接把“/ruby”理解为“category是ruby”，也就是说“ruby”出现的位置说明了它指的就是category。OK，/ruby/articles，单单从这个url上看，我们能获得多少关于category的信息呢？显然category隐藏在了url后面，这样做到底好不好，应该是仁者见仁，智者见智了。对于如何表达category这样的东西，我还没想出很好的方式，大家有什么好idea，可以一起讨论。

另外还有一种url形式，它对应到程序中的继承关系。比如product是一个父类，book和computer是其子类。那么所有产品的url应该是/products，所有书籍的url应该是/books，所有电脑的url应该是/computers。这一想法就比较直观了，而且再次验证了url可以帮助我们进行设计的论点。

让我再说明一下我的想法：如果每个用户需求都可以抽象为资源，那么就可以完全使用REST。

由此看来，使用REST的关键是如何抽象资源，抽象得越精确，对REST的应用就越好。因此，如何改变我们目前根深蒂固的基于action的思想是最重要的。

有了对第一个问题的讨论，第二个问题就容易讨论多了。REST会取代MVC吗？还是彼此是互补关系（就像AOP对于OOP）？答案是It depends！如果我们可以把所有的用户需求都可以抽象为资源，那么MVC就可以推出历史的舞台了。如果情况相反，那么我们就需要混合使用REST和MVC。当然，这是非常理想的论断。可能我们无法找到一种方法可以把所有的用户需求都抽象为资源，因为保证这种抽象的完整性（即真的是所有需求都可以）需要形式化的证明。而且即使被证明出来了，由于开发人员的能力和喜好不同，MVC肯定也会成为不少人的首选。但是对于希望拥抱REST的人来说，这些都没有关系。只要你开发的系统所设计的问题域可以被合理地抽象为资源，那么REST就会成为你的开发利器。

所以，所有希望拥抱REST的朋友们，赶快训练自己如何带上资源的眼镜看世界吧，这才是REST的核心所在。

http://foo.extremepattern.com/index.php?title=Hello_REST wiki: Hello REST

。。。REST 是一種風格 Style，不是一種技術 Technology。
http://foo.extremepattern.com/index.php?title=Hello_Restlet wiki：Hello Restlet 

。。。在整個嘗試過程中，最讓人難以確認是否做好的部份是在 URI 的設計，它必須是資源的獨一無二的地址，至於 Uniform Interface 的限制，反而容易做到，因為只有四個動詞。RESTify DayTrader 一文做了很好的示範，示範如何將動詞取出，分析名詞，設計
 URI 標示資源與資源的操作方式。 

。。。How to Create a REST Protocol這篇文章提供很好的指引，這裡列出 RESTful Web Services 書中的建議步驟。 【虎.无名：推荐一看 http://www.xml.com/pub/a/2004/12/01/restful-web.html】
Figure out the data set
Split the data set into resources
Name the resuorces with URIs
Expose a subset of the uniform interface
Design the representation(s) accepted from the client
Design the representation(s) served to the client
Integrate this resource into existing resources, using hypermedia links and forms
Consider the typical course of events:what's supposed to happen?
Consider error conditions: what might go wrong?

HTTP Method CRUD Action Description POST CREATE Create a new resource GET RETRIEVE Retrieve a representation of a resource PUT UPDATE Update a resource DELETE DELETE Delete a resource

We'll update our table for our employee contact list to include the expected status codes

Resource Method Representation Status Codes Employee GET Employee Format 200, 301永久重定向, 410永久不可用 Employee PUT Employee Format 200, 301, 400错误请求, 410 Employee DELETE N/A 200, 204无消息体 All Employees GET Employee List Format 200, 301 All Employees POST Employee
 Format 201成功创建, 400
Warning Signs

Even following these steps, you could still make some mistakes. Paul Prescod has created a list of Common REST Mistakes that is worth reviewing as you work on your protocol.

http://www.prescod.net/rest/mistakes/ 【虎.无名：需要重视】When designing your first REST system there are a variety of mistakes people often make. I want to summarize them so that you can avoid them.
 If any are unclear, ask for more information on rest-discuss.
Using HTTP is not enough. 【虎.无名：不仅仅把HTTP当作传输协议，而是一个应用协议。充分利用HTTP头信息和响应码。】
Do not overuse POST. 【虎.无名：不要过渡使用POST方法，按需要使用DELETE和PUT，如果浏览器不支持，可以考虑客户端用ajax技术来实现。】
Do not depend on URI's internal structure. 【虎.无名：URI是用户接口，只和用户需求相关，无需将URI绑定内部数据结构或数据库接口】
Do not put actions in URIs. 【虎.无名：URI只和资源（名词）相关，与行为（动词）无关。】
Services are seldom resources. 【虎.无名：服务很少是资源？一个资源可支持多种服务。也可这么理解：资源是一个类，而服务是类的一个方法。】
Sessions are irrelevant. There should be no need for a client to "login" or "start a connection." HTTP authentication is done automatically on every message. Client applications are consumers of resources, not services. Therefore
 there is nothing to log in to! Let's say that you are booking a flight on a REST web service. You don't create a new "session" connection to the service. Rather you ask the "itinerary creator object" to create you a new itinerary. You can start filling in
 the blanks but then get some totally different component elsewhere on the web to fill in some other blanks. There is no session so there is no problem of migrating session state between clients. There is also no issue of "session affinity" in the server (though
 there are still load balancing issues to continue). 【虎.无名：登录认证似乎需要独立于REST系统，在前端WebServer上完成？】
Do not invent proprietary（私有的） object identifiers. Use URIs. URIs are important because you can always associate information with them in two ways. 1）The simplest way is to put data on a web server so that the URI can be
 dereferenced in order to get the data. Note that this technique only works with URIs that can be dereferenced so these URIs (http URIs!) are strongly preferred to URN or UUID-based URIs. 2）Another way is to use RDF and other techniques that allow you to project
 metadata onto a URI that may not be under your control.

If you use URI syntax with UUIDs or something like that then you get half of the benefit of URIs. You get a standardized syntax but have no standardized dereferencing capability. If you use an HTTP URI then you get the other half of the benefit because you
 then also have a standardized derferencing mechanism. 【虎.无名：没太明白，不要发明私有对象ID？】
Do not worry about protocol independence. There exists only one protocol which supports the proper resource manipulation semantics. If another one arises in the future, it will be easy to keep your same design and merely
 support the alternate protocol's interface. On the other hand, what people usually mean by "protocol independence" is to abandon resource modelling and therefore abandon both REST and the Web. 【虎.无名：HTTP协议本身已经足够通用了】

Overall, the thing to keep in mind is that REST is about exposing resources through URIs, not services through messaging interfaces.【REST通过URL暴露资源，而不是通过消息接口暴露服务。虎.无名：暴露一个资源，是不是意味着该资源的所有操作都需要暴露？】

REST由Roy Fielding于2000年在他的博士论文中引入和定义。REST是用于设计分布式系统的架构风格。它不是标准，而是一组约束，例如无状态，具有客户端/服务器关系和统一接口。REST与HTTP并不严格相关，但最常与它相关联。

REST原理


Resources 公开易于理解的目录结构URI。
Representations 传输JSON或XML以表示数据对象和属性。
Messages 显式使用HTTP方法（例如，GET，POST，PUT和DELETE）。
Stateless 交互在请求之间不在服务器上存储客户端上下文。状态依赖性限制并限制可伸缩性。客户端保持会话状态。


HTTP方法

使用HTTP方法将CRUD（创建，检索，更新，删除）操作映射到HTTP请求。

GET

检索信息。GET请求必须是安全且幂等的，这意味着无论使用相同参数重复多少次，结果都是相同的。它们可能有副作用，但用户并不期望它们，因此它们对系统的操作不是至关重要的。请求也可以是部分或有条件的。
检索ID为1的地址：
GET /addresses/1


POST

请求URI上的资源对提供的实体执行某些操作。POST通常用于创建新实体，但也可用于更新实体。
创建一个新地址：
POST /addresses


PUT

将实体存储在URI中。PUT可以创建新实体或更新现有实体。PUT请求是幂等的。幂等性是PUT与POST请求的期望之间的主要区别。
修改ID为1的地址：
PUT /addresses/1

注意: PUT替换现有实体。如果仅提供数据元素的子集，则其余的将替换为空或null。

PATCH

仅更新URI上实体的指定字段。PATCH请求既不安全也不是幂等（RFC 5789）。这是因为PATCH操作无法确保整个资源已更新。
PATCH /addresses/1


DELETE

请求删除资源; 但是，不必立即删除资源。它可能是异步或长时间运行的请求。
删除ID为1的地址：
DELETE /addresses/1


HTTP状态代码

状态代码表示HTTP请求的结果。

1XX - 信息
2XX–成功
3XX - 重定向
4XX - 客户端错误
5XX - 服务器错误


媒体类型

Accept和Content-Type HTTP头可以用来描述在HTTP请求中发送或请求的内容。如果客户端请求json格式的响应，则可以将Accept设置为application/json。相反，在发送数据时，将内容类型设置为application/xml会告诉客户机请求中发送的数据是xml。