REST是在做Web时常常听说的一个出现了很久的概念，REST的全称是Representational State Transfer即表述性状态转移，Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。它是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。
提到REST，就不得不提到SOAP，在REST出现，流行之前，一直是SOAP的天下，SOAP的全称是Simple Object Access Protocol，这是一种简单的基于XML的协议，从字面的意思理解就是简单对象访问协议，是一种用于访问网络服务的协议。SOAP和REST一个很大区别在于SOAP使用XML描述数据而REST使用JSON描述数据，XML和JSON都是一种通用的描述数据的格式，他们都与语言无关，一个数据的描述与语言无关可以方便在不同的语言之间交换数据，可以在不同的语言之间交换数据意味着可以使用一种语言去调用另外一种语言，为我们的开发提供了很大的便捷。
那么SOAP存在着一个什么样的问题呢?在互联网高速发展的当代，人们越来越倾向于使用轻量化的协议，在这种情况下，SOAP就显得太重了。在REST出现之前，前端的JS都不会直接去访问服务器的接口，通常不提倡前端(JS)直接访问公共服务，因为浏览器有跨域限制，前端和公共服务不在一个域，不能直接访问。当时的做法是提供了SOAP形式，SOAP会生成WSDL的代理类，存放在网站后台，使用JS访问后台代码，再由后台代码使用公共服务提供的代理类来访问代理类。而REST的出现，最大的意义便是提供了一种更轻量化的思维方式。
REST和RESTFul API有些什么区别呢?
简单地说，REST是中的思想和理论，而如果我们把REST用于Web API的接口设计，就会产生RESTFul风格的API，简单来说，RESTFul API是REST在Web接口中的应用和延伸。
RESTFul API的设计的一些原则：
1.轻
2.使用JSON描述数据(使用json格式返回数据)
3.无状态：假设用户发送了两个http请求，这两个http请求没有先后顺序，两个请求之间没有直接关系，第二个请求是不依赖于第一个请求的
(举个反例：有状态如数据库访问时，通常需要先连接才能做增删改查等操作，增删改查等操作是建立在连接了数据库的操作上的)
4. REST提倡所有的接口都是基于资源的，所有的增删改查操作都是对于资源状态的改变
5. 使用HTTP动词来操作资源(表示资源的方法：URL，REST服务中建议不要在URL中出现动词而只出现名词，提倡使用http动词操作资源，使用http动词描述资源状态的增删改查：get查询，put更新，post创建，delete删除)，URL的语义要明确，最好可以望文生义
在传统WEB开发中，选择请求方式并不是根据资源的增删改查，而是依据参数传递的方式
在REST服务中选择请求方式必须取决于你的操作，例:GET:/movie/:mid
6. 对每一个HTTP请求的相应结果都要指明一个状态码(如404,400等)
tip：即使不做任何操作，每一个http都会自动携带一个状态码，如GET操作不特别指明时会设置为200(一般由框架设定)，状态码的意义一般是要特别明确的
常用状态码：
404：当前请求的资源没有找到
400：参数错误
200：查询操作GET请求成功
201：POST创建成功(有些API如豆瓣，将PUT和POST请求成功都设置为201)
202：PUT更新请求成功/在http请求中本身状态码：请求已经发送但是服务器没有处理
401: 没有访问权限
403：访问的资源被禁止了/或者有两个都有操作权限的用户有个用户想去操作另一个用户的数据时
500：未知错误/不希望被客户端知道的服务器的错误
除了状态码外，通常还需要错误码，错误码是具体错误的编号。当产生错误会返回一个JSON格式的统一描述错误：由错误码，错误信息，当前产生错误的URL组成(并不是唯一标准)。
9. 在RESTFul API使用token令牌来授权和验证身份，在网站中通常使用session和cookie来保存和传递用户身份信息，在API中通常使用token令牌，
cookie和token在本质上没有太大区别但是实现机制有所不同，cookie在很多时候是浏览器的行为，访问时浏览器会自动携带cookie，而token更多时候是由我们自己存储和管理。
10. API的版本号，实现对版本控制的支持
11. 测试与生产环境分开
目前，比较常用的标准的RESTFul API有豆瓣API以及GitHub开发者API，我们想开发一套比较标准的RESTFul API时，这两个API是比较好的参考的对象，在开发过程中，我们要合理使用RESTFul API，切勿盲目照搬标准REST，上面提到的豆瓣API和GitHub开发者API是开放API，通常我们的API并不对所有人开放，通常针对于我们的前端，也就是常说的是内部开发接口，设计时也并不要仅仅局限于单纯的增删改查，通常一个操作我们也会有分为几种类型，而当我们将所有的一个类型的操作设计为一个接口时，代码会相当复杂，URL传参也会相当的复杂，因此设计时需要根据实际情况来进行设计。