前言
在SpringMVC架构上进行开发，开发者一直在使用jsp、valocity或者其他页面模版作为表现层面，前端工程师需要将设计师的设计图转换为静态的html页面，然后交付给后端将静态的html页面转换为页面模版、数据的显示、页面的js基本都是由后端工程师去实现。
更糟糕的是，将数据渲染到页面模版上时，往往都会出现排版、样式错乱的情况，需由后端工程师自己调试，或请前端工程师在后端的开发环境进行调试，这样降低了开发效率，所以越来越多的互联网公司开始进行了前后端分离。
前后端分离的好处：后端接口只需要出一套统一的Restful接口，就可以适配多个客户端、web页面、ios设备、Android设备、PC、微信公众号、微信小程序等。
Restful统一接口
什么是REST
rest是Representational State Transfer三个单词的缩写，由Roy Fielding于2000年论文中提出的一种web软件结构风格，注意它仅仅只是代表着一种风格，并不代表着约束、标准。基于REST构建的API就是Restful风格。
REST架构风格的设计原则
客户端-服务器(Client-Server)客户端-服务器结构限制的目的是将客户端和服务器端的关注点分离。将用户界面数据存储所关注的逻辑分离开来有助于提高用户界面的跨平台的可移植性，通过简化服务器模块也有助于服务器模块的可扩展性
无状态(Stateless)服务器不能保存客户端的信息每一次从客户端发送的请求中, 要包含所有的状态信息, 会话信息由客户端保存, 服务器端根据这些状态信息来处理请求。服务器可以将会话状态信息传递给其他服务, 比如数据库服务, 这样可以保持一段时间的状态信息, 从而实现认证功能。当客户端可以切换到一个新状态的时候发送请求信息。当一个或者多个请求被发送之后, 客户端就处于一个状态变迁过程中。 每一个应用的状态描述可以被客户端用来初始化下一次的状态变迁
缓存(Cacheability)如同万维网一样, 客户端和中间的通讯传递者可以将回复缓存起来。回复必须明确的或者间接的表明本身是否可以进行缓存, 这可以预防客户端在将来进行请求的时候得到陈旧的或不恰当的数据。管理良好的缓存机制可以减少客户端-服务器之间的交互, 甚至完全避免客户端-服务器交互, 这进一步提了高性能和可扩展性
统一接口(Uniform Interface)这是 RESTful 系统设计的基本出发点。它简化了系统架构, 减少了耦合性, 可以让所有模块各自独立的进行改进各自独立的进行改进
Restful API架构风格中请求规范规范
一、http状态码：
使用http状态码定义api执行结果，http 定义了一系列可以用在接口返回的有含义的状态码。下面是常用状态码解释：
二、路径规范：
01 分隔符对于REST API来说，"/"只是一个分隔符，并无其他含义。为了避免混淆，"/"不应该出现在URL的末尾。例如以下两个地址实际表示的都是同一个资源：
REST API对URI资源的定义具有唯一性，一个资源对应一个唯一的地址。为了使接口保持清晰干净，如果访问到末尾包含 "/" 的地址，服务端应该301到没有 "/"的地址上。当然这个规则也仅限于REST API接口的访问，对于传统的WEB页面服务来说，并不一定适用这个规则
02 路径中使用连字符 -代替下划线 _连字符"-"一般用来分割URI中出现的字符串(单词)，来提高URI的可读性，例如：
使用下划线"_"来分割字符串(单词)可能会和链接的样式冲突重叠，而影响阅读性。但实际上，"-"和"_"对URL中字符串的分割语意上还是有些差异的："-"分割的字符串(单词)一般各自都具有独立的含义，可参见上面的例子。而"_"一般用于对一个整体含义的字符串做了层级的分割，方便阅读，例如你想在URL中体现一个ip地址的信息：210_110_25_88
对于参数名称，使用下划线进行连接，比如 app_id
03 路径中统一使用小写字母根据RFC3986定义，URI是对大小写敏感的，所以为了避免歧义，我们尽量用小写字符。但主机名(Host)和scheme(协议名称:http/ftp/…)对大小写是不敏感的
三、请求方式http method对应不同的请求动作
总 结Restful API的接口架构风格中制定了一些规范，极大的简化了前后端对接的时间，以及增加了开发效率，在实际开发中，比如在获取列表分页的时候，对于查询参数过多的接口，会导致uri的长度过长、请求失败，在这种情况下的接口就不能完全按照Restful API的请求规范来。Restful API也就只是一种接口架构的风格，接口API永远不会强约束于此，因按照实际需求做出相应的接口需改。
作者：吴勋 编辑：詹思璇