【API规范】聊聊先后端分离接口规范

前言

在移动互联网，分布式、微服务盛行的今天，先后端的工做职责愈来愈明确，前端页面的展现、交互体验愈来愈灵活、炫丽，响应体验也要求愈来愈高，后端服务的高并发、高可用、高性能、高扩展等特性的要求也越发苛刻，而带来的另外一个问题：先后端的对接界面双方却关注甚少，没有任何接口约定规范状况下各自干各自的，致使咱们在产品项目开发过程当中，先后端的接口联调对接工做量占比在30%-50%左右，甚至会更高。

为什么要分离

前端开发重度依赖开发环境，开发效率低。

前端工程师作html页面，写好后，后端工程师将html页面套成jsp页面，好处很明显，能够本地开发，很高效，但若是html发生变动，那你就惨了，并且模板是后端套的，颇有可能套错，套完后还须要前端肯定，来回沟通调整的成本比较大。

先后端职责依旧纠缠不清。

之前的JavaWeb项目大多数都是java程序员又当爹又当妈，又搞前端，又搞后端。

大多数项目都是MVC架构，控制层，业务层，持久层。控制层负责接收参数，调用相关业务层，封装数据，以及路由&渲染到jsp页面，但前端要是弱势一点，每每就会被后端要求在模板层写出很多业务代码,还有一个很大的灰色地带是 Controller，页面路由等功能本应该是前端最关注的，但倒是由后端来实现。Controller 自己与 Model 每每也会纠缠不清，看了让人咬牙的业务代码常常会出如今 Controller 层。这些问题不能全归结于程序员的素养，不然 JSP 就够了。

先后分离的优点

1. 实现真正的先后端解耦，前端服务器使用nginx，前端/WEB服务器放的是css，js，图片等等一系列静态资源（甚至你还能够css，js，图片等资源放到特定的文件服务器，例如阿里云的oss，并使用cdn加速）
2. 发现bug，能够快速定位是谁的问题，不会出现互相踢皮球的现象。
3. 减小后端服务器的并发/负载压力。除了接口之外的其余全部http请求所有转移到前端nginx上，接口的请求调用tomcat，参考nginx反向代理tomcat。
4. 即便后端服务暂时宕机了，前端页面也能够正常访问，只不过看不到数据。
5. nginx支持页面热部署，不用重启服务器，前端升级更无缝。
6. 增长代码的可维护性，先后端耦在一块儿的代码维护成本很高。
7. 在nginx中部署证书，外网使用https访问，而且只开放443和80端口，其余端口一概关闭，内网使用http，性能和安全都有保障。

如何作分离

分离职责

先后端仅经过异步接口来编程，先后端都各自有本身的开发流程，构建工具，测试集合。

开发流程

1. 先后端约定接口&数据&参数
2. 先后端并行开发（前端根据接口文档进行开发 + Mock平台）
3. 开发完成后联调和提交测试

Mock 服务器根据接口文档自动生成 Mock 数据，实现了接口文档即API：

接口规范

规范原则

1. 接口返回数据即显示：前端仅作渲染逻辑处理
2. 渲染逻辑禁止跨多个接口调用
3. 前端关注交互、渲染逻辑，尽可能避免业务逻辑处理的出现
4. 请求响应传输数据格式：JSON，JSON数据尽可能简单轻量，避免多级JSON的出现

基本格式

请求格式

get

user/login?body={"uname":"root","pwd":"root"}
复制代码

post

返回格式

{
  code:200,        //返回状态码
  message:'请求成功',  //返回信息描述
  data:object  //返回值
}
复制代码

CODE状态码

• 200 - 请求成功
• 301 - 资源（网页等）被永久转移到其它URL
• 404 - 请求的资源（网页等）不存在
• 500 - 内部服务器错误