App与服务器的通信接口如何才能设计得更好？( 二 ) _App

0：成功
100：请求错误
101：缺少appKey
102：缺少签名
103：缺少参数
200：服务器出错
201：服务不可用
202：服务器正在重启

错误信息一般有两种用途：一是客户端开发人员调试时看具体是什么错误；二是作为App错误提示直接展示给用户看。主要还是作为App错误提示，直接展示给用户看的。所以，大部分都是简短的提示信息。
data字段只在请求成功时才会有数据返回的。数据类型限定为对象或数组，当请求需要的数据为单个对象时则传回对象，当请求需要的数据是列表时，则为某个对象的数组。这里需要注意的就是，不要将data传入字符串或数字，即使请求需要的数据只有一个，比如token，那返回的data应该为：
// 正确data: { token: 123456 }// 错误data: 123456接口版本的设计接口不可能一成不变，在不停迭代中，总会发生变化。接口的变化一般会有几种：

数据的变化，比如增加了旧版本不支持的数据类型
参数的变化，比如新增了参数
接口的废弃，不再使用该接口了

为了适应这些变化，必须得做接口版本的设计。实现上，一般有两种做法：

每个接口有各自的版本，一般为接口添加个version的参数。
整个接口系统有统一的版本，一般在URL中添加版本号，比如http://api.domain.com/v2 。

大部分情况下会采用第一种方式，当某一个接口有变动时，在这个接口上叠加版本号，并兼容旧版本。App的新版本开发传参时则将传入新版本的version 。
如果整个接口系统的根基都发生变动的话，比如微博API，从OAuth1.0升级到OAuth2.0，整个API都进行了升级。
有时候，一个接口的变动还会影响到其他接口，但做的时候不一定能发现。因此，最好还要有一套完善的测试机制保证每次接口变更都能测试到所有相关层面。
写在最后关于接口设计，暂时想到的就这么多了。各位看官看完觉得有遗漏或有哪些需要优化的欢迎提出一起讨论

【App与服务器的通信接口如何才能设计得更好？】