Ajax请求响应数据格式的设计

在日常开发中，ajax必须是占了很重要一部分的，其如何重要本文就不说，本文着重讲的是ajax返回数据的json格式的设计。

因为本人在维护一个大网站的工作中，看着前人留下的代码，看到那些散乱低效的对ajax返回数据的验证、判断、处理，确实发现存在很多问题。

所以我觉得，设计一个良好的响应数据格式是必要的，再配合设计出一个简单高效的处理失败数据（返回不成功的响应码）的机制（或者说函数），那么将很有利于提高代码性能和后续维护。

废话不说，上代码：

{code:响应码, msg:'提示文案', data:{...}}

我觉得最重要、最必要的也就这三部分。

msg：后台返回的提示文案，有时候文案应该存放在后台，而不是存放在前台，这样后台看到对应的响应码就知道具体的码值代表的意义，方便后台维护。至于后台如何管理和维护所有的响应码和文案，在稍候做介绍。

data：详细数据，当返回成功码或需要处理数据的想。

code：一个请求，成功与否（包括前端提交的数据是否有问题、后端查询的数据是否有问题、后端操作是否成功等等），用一个响应码加以标识，这样很方面前端对返回数据进行处理。但是，响应码怎么设计，是值得思考思考的。

一、响应码的设计

为了最小化ajax响应数据，我把响应码的数据类型定为整型，使用字符串得多了前后两个引号，还有，判断响应码范围的时候，直接比较值大小就可以。

各种值的意义：

1：请求成功

2：非法的请求参数

...

这些100000以内的值为通用的值，应该是每个请求都会涉及到的状态。（实际中通用的码怎么也不会这么多的）

随着时间的推移，肯定会不断增加响应码，这时候，按照年份和月份来设计码值，这样可以避免重复。比如12年2月份添加的第一个码值就是120201，13年05月添加的第35个码值就是130535，以此类推。但是可以发现，这样每个月最多只有99个码值，估计对99%的项目够了，但是不排除极品变态的项目会超过99个，这时候的解决办法是把月份加上12。比如12年2月份添加的第100个码值就是121400（其实个人不喜欢某部分出现0的情况，所以建议去掉第100个，超过99的又从01开始，记成121401），接着是121402，以此类推。

二、提示文案的管理

一部分文案是只在前端存在的，比如提交表单时通过前端来判断提交数据是否有效，数据无效时，前端必须做出提示，这时候的提示文案显然是放在前端的。

如果一个项目很大，其实不管大不大，文案都必须统一管理，方便更改文案。

放在前端的文案，要存到一个对象里：

if(typeof $MSG === 'undefined'){
$MSG = {
2: '非法的请求参数',
3: '....',
4: '...'
};
}

对于非通用的文案，即以年月开始的文案，每条文案放到一个文件里，文件以码值命名（例如“130535.js”，防重），所有文件放到一个文件夹下。每个文件的代码如下：

$MSG[130535] = '这是第130535号提示！';

而每个网页面应该有一个文案配置文件，这个文件里引入该网页需要的所有文案，这样此页面里需要用文案的所有模块直接引用这个文件即可。

如果文案只存放在后台，那么对应的码值的年份应该加上50，以方便判断提示文案应该从哪取，例如13年05月添加的第35个文案只存在后台的响应码，码值就是630535（年份加了50）。如此，响应码大于500000，就从响应数据里取msg属性（当然你可不管三七二十一先尝试从响应数据里取msg属性），小于500000就从$MSG对象里取。

这两个比较重要的部分设计好之后，就是响应数据的处理流程：

1、判断响应码是不是1，是的话调用请求成功的回调函数就行了，结束流程。

2、响应码不是1，用响应码获取文案，谈提示框，进行相应的处理。（这个处理策略又是一个比较重要的设计，要让框架灵活好用，每个细节都应该精心地设计。这里不说了。）