本人第一次设计供给移动端的API，中间遇到些困惑，想咨询下各位有经验的前辈，目前服务端使用的是Java：
1.返回的参数对所有接口都统一化还是各个接口区分对待？
我理解的统一化：{message:"XXX", code:"XXX", data:"不同接口的数据集"}
我理解的区分化：{message:"XXX", code:"XXX", users:"用户结果数据集"}、{message:"XXX", code:"XXX", reposities:"资源库数据集"}
2.看了github的API接口，较长的参数一般使用下划线拼接，如：following_url，html_url字段。现在服务端是Java语言，Java语言对参数的命名都是驼峰风格，那么我返回的参数是按照驼峰设计呢还是类似于github的方式？
3.以前是做Java支付交易系统的，时间都是YYYYMMDD、HHMMSS格式的，现在在做社交类型的系统，朋友推荐说使用时间戳或者格式化好的YYYYMMDD类型，所以请教下大家对返回的时间戳一般是怎么设计的？
4.Token一般是放在后台在Head里面返回客户端，客户端在请求时也是在放在Head里面吧？
对于Token的设计，我想的是保存在数据库里面，每次请求时通过查询数据库校验是否正常，但这样每次都查询数据库是很慢的，有没有把token放在缓存里面（memcached或者redis）的做法？
首先回答一下第一个第二个，如果你参照的风格是restful的话，那么你这套接口应该是通用的，json只是一个字符串，因此，采用什么风格就看你们约定好的，通常我们都是用下划线，另外你说的统一化这个也是根据需求设定的，根据需要设置字段，但是通常code msg status这种在每一个api都应该要有，data字段应该是一个json对象，里边的对象属性就要根据你的接口作用设置了，这就是区别化（个人风格，仅代表个人观点），第三个问题为了通用化，你可以把时间戳弄成long类型的，根据客户端的语言再转化成yyyyMMdd这种，建议不要先转再发。第四个问题，token是为了安全而设定的，那么你可以采用客户端先请求token，每一次都不一样，然后在后端弄成一个映射，当客户端请求api的时候携带token，根据token直接映射到对应的用户。
我觉得区分开来比较好。前端都用js解析json字符串，解析完之后，不存在的属性就是
undefined，前端用户可以判断是否为undefined进行区分处理。我见过的一些接口就是成功的时候没有error属性，只在失败的时候才有。这样可以节省一些字节传输。命名我觉得比较随便了，你跟前端同学沟通一下就行。只要保证统一即可，不要一会儿是下划线一会又是驼峰
同意楼上意见，返回一个long类型的unix时间即可。这样你获取方便，下游的同学也方便转换。要不然还得一直记着你的字符串格式。一旦出现其他同学接手就可能出现混乱。
token可以放到内存里，这种用法比较多。定一个过期时间，一旦过期从内存消除即可。当请求较多，实时性要求较高而内存也充裕的时候建议这样。
1、统一，减少与前端的沟通成本，也方便前端统一处理；
2、可以驼峰，也可以下划线，只要内部统一一种风格就好了，记忆中Jackson序列化时有个设置可以让驼峰格式转换成下划线格式的（反序列化时同理）；
3、用时间戳，由前端格式化时间显示，方便同一接口在不同地方调用时可以显示不同的时间格式；
4、Token一般有时效性，没有必要放到数据库里，一般用Memcached或Redis存储并设置过期时间。
更新：Jackson的驼峰转下划线配置：
objectMapper.setPropertyNamingStrategy(PropertyNamingStrategy.CAMEL_CASE_TO_LOWER_CASE_WITH_UNDERSCORES);1.必须统一，要是每个接口都不一样，客户端写代码要疯了，到时候调试你们都要疯了
大部分通用的规则是
{code:'',msg:'',data:{}}
code:当前状态码，这个后台配置不同响应不同状态码
msg：正常返回或者发生异常返回的提示信息
data:data可以是对象或者数组，返回数据
2.java的话一般驼峰
3.时间这个要看每个界面不同，你不可能所有界面返回的时间都一种格式吧，这个没必要弄的那么一样吧我觉得
4.token放head body都行，业务够大了可以放内存，redis memcached什么的 nosql的都行，量小就查库，没必要那么复杂了