APP接口设计规范
- 效率
- 安全
- 版本兼容性
- 面向对象设计
- 数据格式Json
- 服务端的异常处理
- https协议
1.效率
APP对服务器端要求是比较严格的，在移动端有限的带宽条件下，要求接口响应速度要快，所有在开发过程中尽量选择效率高的框架，对数据要求也比较严格，app需要什么数据就传什么数据，不可多传，过多的数据量影响处理速度，最重要的是影响传输效率。接口要规范，以面向对象的思想设计接口。
##2.安全
接口请求成功或失败，需要有明确的标识符来表示。并且对错误原因进行描述。同时因为客户端可能是多语言的，错误原因应该设计为errorCode，由客户端根据errorCode来显示成对应的语言；此外，不允许出现同一个接口返回不同数据格式的json包；为应对被抓包的风险，客户端和服务端也需要有一套约定的算法加密，可以是对称加密，非对称加密，也可以反复加密，此外，对有必须登录要求的私密性app，比如社交类的，金融类的app，需要在登陆后返回token，所有接口请求都需要带token参数，当有第二只手机登录这个账号，则新生成一个token，旧token失效，失效的请求返回失效的返回code,让客户端退出至登录页面，如果一个账号在固定一段时间里频繁换token，那么就要考虑这个账号被盗的可能性。
##3.版本兼容性
接口不可能永远不变，它会随着需求的变化而做出相应的变动。接口的变化一般会有几种：
数据的变化，比如增加了旧版本不支持的数据类型
参数的变化，比如新增了参数
接口的废弃，不再使用该接口了
为了适应这些变化，必须得做接口版本的设计。实现上，一般有两种做法：
1.每个接口有各自的版本，一般为接口添加个version的参数。
2.整个接口系统有统一的版本，一般在URL中添加版本号，比如http://api.demo.com/v2。
大部分情况下会采用第一种方式，当某一个接口有变动时，在这个接口上叠加版本号，并兼容旧版本。App的新版本开发传参时则将传入新版本的version。
如果整个接口系统的根基都发生变动的话，比如微博API，从OAuth1.0升级到OAuth2.0，整个API都进行了升级。
有时候，一个接口的变动还会影响到其他接口，但做的时候不一定能发现。
##4.面向对象设计
我们在对接口做设计的时候，要充分考虑客户端的界面显示，比如客户端的界面显示是一个列表，那么json数据格式对应的就应该是**[]**数据类型，这里需要补充一下，Json的值只有六种数据类型：
- Number：整数或浮点数
- String：字符串
- Boolean：true 或 false
- Array：数组包含在方括号[]中
- Object：对象包含在大括号{}中
- Null：空类型
像java里面的Date类型，那肯定是需要做转化的
我是做二手车app的，对于车子面向对象举例，以下有两种设计模式
我的建议是第一种设计模式，该对象对应的json包为
{
“brandName”:“奥迪”,
“carModel”:“SUV”,
“emissionStandard”:“国五”,
“carOwner”:{
“name”:“张三”,
“drivingYears”:“5年”,
“id”:“**”
}
}
这样的设计更加符合客户端MVC的设计模式，如果我们有这样一个功能，点击车主能在二级页面看到车主的信息，那么我们只要将车主的模型传到第二个页面即可。那么这样将大大减少客户端的数据处理时间。
##5.数据格式Json
服务器返回的数据结构，一般为：
{
code：200
message: “success”
data: { key1: value1, key2: value2, … }
}
code: 状态码，200表示成功，非0表示各种不同的错误，可自定义code，客户端和服务端约定即可。
message: 描述信息，成功时为"success"，错误时则是错误信息
data: 成功时返回的数据，类型为对象 , 因此，data的返回必须是{}的格式，或者传一个null,如果Object类型变成了String类型，那么肯定是报错的。
##6.服务端的异常反馈
服务端的程序在运行的时候，可能因为一个数据的转化或空指针异常什么的，都不能让程序奔溃，需要捕获异常并对异常进行处理，并返回明确的数据状态信息，不管是成功的，还是失败的，都必须要有数据返回给APP客户端，否则，接口的协议失去了所有的意义
##7.https协议
对于敏感的api接口，需使用https协议
https是在http超文本传输协议加入SSL层，它在网络间通信是加密的，所以需要加密证书。
https协议需要ca证书，一般需要交费。
