整体规范建议采用Restful方式来实施。
协议：API与用户的通信协议，应该使用https协议，确保交互数据的安全传输。
域名：应该尽量将API部署在专用域名下。如：https://api.example.com。
api版本控制：
方法一：将API的版本号放入URI，如：https://api.example.com/v1。
方法二：将版本号放在http头信息中。这种方法不如放入url中方便和直观。
采用多版本并存，增量发布的方式，v{n}n代表版本号，分为整形和浮点型。
整形的版本号：大功能发布的版本，改动比较多。
浮点型：小版本号，只增加或修改了很小一部分东西。
api路径规则：
路径又称"终点"（endpoint），表示API的具体网址。在RESTful架构中，每个网址代表一种资源（resource），所以网址中不能有动词，只能有名词。
HTTP请求方式：
对于资源的具体操作类型，由http的动词表示。
常用的HTTP动词有下面四个（括号里是对应的SQL命令）。
GET（SELECT）：从服务器取出资源（一项或多项）。
POST（CREATE）：在服务器新建一个资源。
PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。
DELETE（DELETE）：从服务器删除资源。
下面是一些例子。
GET /product：列出所有商品
POST /product：新建一个商品
GET /product/ID：获取某个指定商品的信息
PUT /product/ID：更新某个指定商品的信息
DELETE /product/ID：删除某个商品
GET /product/ID/purchase ：列出某个指定商品的所有投资者
get /product/ID/purchase/ID：获取某个指定商品的指定投资者信息
返回数据
只要api接口成功接到请求，就不能返回200以外的HTTP状态。
为了保障前后端的数据交互的顺畅，建议规范数据的返回，并采用固定的数据格式封装。
接口返回模板：
{
status:0,
data:{}||[],
msg:’’
}
status: 接口的执行的状态:
=0表示成功
<0 表示有异常=""
Data 接口的主数据可以根据实际返回数组或JSON对象
Msg:
当status!=0 都应该有错误信息
非Restful Api的需求
由于实际业务开展过程中，可能会出现各种的api不是简单的restful 规范能实现的，因此，需要有一些api突破restful规范原则。特别是移动互联网的api设计，更需要有一些特定的api来优化数据请求的交互。
页面级的api
把当前页面中需要用到的所有数据通过一个接口一次性返回全部数据
举例
api/v1/get-home-data 返回首页用到的所有数据
这类API有一个非常不好的地址，只要业务需求变动，这个api就需要跟着变更。
自定义组合api
把当前用户需要在第一时间内容加载的多个接口合并成一个请求发送到服务端，服务端根据请求内容，一次性把所有数据合并返回,相比于页面级api，具备更高的灵活性，同时又能很容易的实现页面级的api功能。
规范
地址：api/v1/batApi
传入参数：
data:[
{url:'api1',type:'get',data:{...}},
{url:'api2',type:'get',data:{...}},
{url:'api3',type:'get',data:{...}},
{url:'api4',type:'get',data:{...}}
]
返回数据
{status:0,msg:'',
data:[
{status:0,msg:'',data:[]},
{status:-1,msg:'',data:{}},
{status:1,msg:'',data:{}},
{status:0,msg:'',data:[]},
]
}