【原创文章，转载请注明原文章地址，谢谢！】
在上一篇文章中，我们从一个实际开发中遇到的需求，对REST做了一个简单粗暴的介绍。在有了一些大概的理解之后，我们在这篇文章中对REST的一些基本概念再进行阐述。
先借用百度百科，对REST的来龙去脉做一个简单的介绍。
Web发展到了1995年，在CGI、ASP等技术出现之后，沿用了多年、主要面向静态文档的HTTP/1.0协议已经无法满足Web应用的开发需求，因此需要设计新版本的HTTP协议。在HTTP/1.0协议专家组之中，有一位年轻人脱颖而出，显示出了不凡的洞察力，后来他成为了HTTP/1.1协议专家组的负责人。这位年轻人就是Apache HTTP服务器的核心开发者Roy Fielding，他还是Apache软件基金会的合作创始人。
Roy Fielding和他的同事们在HTTP/1.1协议的设计工作中，对于Web之所以取得巨大成功，在技术架构方面的因素做了一番深入的总结。Fielding将这些总结纳入到了一套理论框架之中，然后使用这套理论框架中的指导原则，来指导HTTP/1.1协议的设计方向。HTTP/1.1协议的第一个草稿是在1996年1月发布的，经过了三年多时间的修订，于1999年6月成为了IETF的正式规范（包括了RFC 2616以及用于对客户端做身份认证的RFC 2617）。HTTP/1.1协议设计的极为成功，以至于发布之后整整10年时间里，都没有多少人认为有修订的必要。用来指导HTTP/1.1协议设计的这套理论框架，最初是以备忘录的形式在专家组成员之间交流，除了IETF/W3C的专家圈子，并没有在外界广泛流传。Fielding在完成HTTP/1.1协议的设计工作之后，回到了加州大学欧文分校继续攻读自己的博士学位。第二年（2000年）在他的博士学位论文Architectural Styles and the Design of Network-based Software Architectures中，Fielding更为系统、严谨地阐述了这套理论框架，并且使用这套理论框架推导出了一种新的架构风格，并且为这种架构风格取了一个令人轻松愉快的名字“REST”——Resource Representational State Transfer（表述性状态转移）的缩写。
所以，讲到REST架构，不得不提一下Architectural Styles and the Design of Network-based Software Architectures这篇论文，而另一个概念，即REST架构是高于HTTP/1.1协议的，HTTP/1.1协议只是REST架构的一种实现方式。所以我们在上篇文章中，才会看到，REST相关的内容在HTTP协议中都可以找到对应的概念，比如请求方式，比如请求头等等。
而实现了REST架构的应用，或者叫遵循了REST架构的应用，我们就叫做RESTful。
概念阐述
下面针对REST中的重要概念做一个简单的阐述，比较理论。
Resource
所谓”资源”，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。你可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。但是注意资源都是名词，所以才有上篇文章中的http://classes.wolfcode.cn/coupons这样的资源URI存在；
Representation
“资源”是一种信息实体，它可以有多种外在表现形式。我们把”资源”具体呈现出来的形式，叫做它的”表现层”（Representation）。
比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现。
URI只代表资源的实体，不代表它的形式。严格地说，有些网址最后的”.html”后缀名是不必要的，因为这个后缀名表示格式，属于”表现层”范畴，而URI应该只代表”资源”的位置。它的具体表现形式，应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对”表现层”的描述。
State Transfer
访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。
互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生”状态转化”（State Transfer）。而这种转化是建立在表现层之上的（因为POST,GET等请求方式属于表现层内容，同理Accept type请求头也属于表现层内容），所以就是”表现层状态转化”。
Uniform Interface
为了让表现层能够按照一个统一的模式去促使服务端资源状态的变化，在HTTP/1.1协议中给应用提供了统一的接口。包括请求方式，请求头，响应头，等等。
以HTTP1.1协议为例：
- 提供了7个HTTP方法：GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS
- 提供了HTTP头信息（可自定义）
- HTTP响应状态代码（可自定义）
这些就是HTTP1.1协议提供的统一接口。此外，REST还要求，对于资源执行的操作，其操作语义必须由HTTP消息体之前的部分完全表达，不能将操作语义封装在HTTP消息体内部。
缩小范围
在本系列文章中，我们只把关注点聚焦于应用接口这块。使用RESTful来完成应用接口的开发。
很多情况下，我们需要把系统的功能作为服务暴露给外部的其他应用使用或者给移动端使用,就需要把系统中的服务作为接口暴露出去,一般分为公共接口和私用接口；对内的接口一般就是内部系统之间的服务的相互调用，比如商城平台中，订单系统和仓储系统之间需要多种接口来处理业务关系，那么这种接口，一般常用的方法，可以使用RPC，RMI，WebService等等，都是可以的。而对外的接口，比如应用提供给App端应用的接口，一般更多使用普通HTTP请求或者RESTful架构。
在本系列文章中，我们就把焦点集中在RESTful在对外接口这块需求上。
小结
通过上面的解释，我们简单的了解了HTTP/1.1和REST之间的关系，了解了REST架构中一些重要概念的理论解释，下一篇文章我们重点姜维放在HTTP/1.1协议给我们提供的统一接口上。
