本文共 4726 字，大约阅读时间需要 15 分钟。
开发多年，遇到的后台有很多，不同的人写的代码风格不一样，写出来的接口也不一样。下面就请求失败的接口举个例子，让大家看看有哪些奇葩的接口。反正我看的想打人了有木有？
大哥，你这是要干啥呢。。。没有错误信息，我怎么知道请求成功还是失败。。这是在挑战我的智商吗？
（建议：下次遇到这样的，直接揍一顿，就说是我说的。下面这张图送给你们后台吧。)
如下所示：
{ 1:"123", 2:"456", 3:"789"} { "result":""} 然而：你给我返回的null什么意思。。。还不如不返回。。。这样设计有啥意义。。
{ "data":"null"} 然而：错误数据返回null不说，错误信息居然返回一个一个url？就这么一点错误信息，还要我再去请求一次服务器获取这个错误信息吗。。
{ "data":"null", "desc":"/error/desc" } /转义字符？{ "error":"//error_desc"} unicode转换的？我用的时候要把它转换回来。。很麻烦。。{ "error":"/%2F%E9%94%99%E8%AF%AF%E4%BF%A1%E6%81%AF"} { "cuowuma": 1, "cuowuxinxi":"请求失败"} 拼音缩写谁看得懂这是干啥用的？猜字谜吗？？？
问题：json里面某些字段是java的关键字，转成实体类的时候，会报错。
{ "abstract": "Success", "id": "503", "package": "50"} 转成实体类如下，会报错：
public class ResultEntity { private String abstract; private String id; private String package; //...get set方法省略}
- 对老司机来说，这种小问题当然也是有解决办法的。使用google提供的序列化工具，按下面这样写，就可以正常的将数据反射到字段中了。
public class ResultEntity { @SerializedName("abstract") private String successInfo; private String id; @SerializedName("package") private String packageNumber; //...get set方法省略}
- tips：按java编程规范来说，接口中是不能包含java关键字的。所以 奉劝各位
后台新手不要心存侥幸心理，一切都要按规范来做，这样对你今后的开发会有很多帮助。
比如下面这个，id字段，前面的是数字类型（我们这边暂定为int类型），最后一个是String类型，后台说是GUID，不管它是什么鬼，看到这种只想打人。万一哪天服务器把id都改成int类型了，客户端这边的代码中涉及到这个id字段的所有地方都要跟着改动，这不是坑爹吗。。。
[ { "id": "503", "name": "License", "picture": "/userfiles/upload/2017/503.png" }, { "id": "504", "name": "其它", "picture": "/userfiles/upload/2017/504.png" }, { "id": "80896a88d8c3449bb90c4781ddbd4d49", "name": "TH inkaNet", "picture": "/userfiles/upload/2017/81211f2db0c649318e7166e447e91186.jpg" }] 举例说明：
{ "data": [ { "id": "101", "info": [ { "name": "张1", "code": "10101" }, { "name": "张2", "code": "10102" }, { "name": "张3", "code": "10103" } ] }, { "id": "102", "info": [ { "name": "张4", "code": "10201" }, { "name": "张5", "code": "10202" }, { "name": "张6", "code": null } ] }, { "id": "104", "info":null } ] } 正确做法： 不管有没有数据返回，都要写清楚返回字段。
比如我遇到过的后台返回的数据举例如下：
有数据返回的时候：
{ "id": "102", "info": [ { "name": "张4", "code": "10201" }, { "name": "张5", "code": "10202" }, { "name": "张6", "code": null } ]} 没有数据返回的时候,info这个json array类型怎么就变成了json object类型？莫名其妙：
{ "id": "102", "info": { "name": "", "code": "" }} 以下是正确做法，请广大
正确做法： 字段结构不能随意修改，不管有没有数据返回都不要随意修改，没有数据的就搞一些默认空值填上去。后台新手get一下：
\转义字符。后台哥们说，你们客户端的自己去拆分解析吧。我看的想打人，你封装成一个对象，用[]返回不行吗？建议：看到这样的json，遇到后台哥们见一次打一次。只想甩他一张图。
请看下图。这是json格式化之后看到的效果，关键字涉及隐私，已打码处理。
这是一个很规范的接口设计，看着很舒服，处理起来很方便。（顺便说一句，推荐大家使用restful风格的接口）
{ "errorCode": 1, "errorMsg": "请求失败", "data": { "message": "Problems parsing JSON" }} java新手 或者 混了几年的老油条，如果你写出的接口是以上这些，或者还有其他的奇葩接口，请好好的反思一下，不要有侥幸心理，认为独立开发或者小公司无所谓，有这种想法的人劝你先去面壁三分钟。
- 1.它是个人基础业务能力的一个展现。
同样3年java开发两个人，一个写的接口条理清晰，结构明确，一目了然；另外一个人写出了类似上面这类的接口。
很明显，前者给人的感觉是基础是比较扎实的。我个人理解，接口编写对于做后台的来说是家常便饭，它算是一门 基本功，就好比练武之人扎马步一个道理。后台跟前端或者客户端交互都要靠接口，接口写不好，还谈什么交互？ 所以，能写出好的接口的人，至少有一点可以看出来，基础是比较扎实的。
- 2.它是代码规范素养的一种体现。
接口写的好的人，可以推断这个人写代码应该也是比较规范的（虽然不能百分之百肯定，但至少它规范的要求自己写接口）。
假如有一天，你能去大公司，你要是写的很差的接口，我敢保证，你也在那里呆不长就被辞退，除非是不注重技术的所谓的大公司。
- 3.为后续接口维护节省了很多时间。
接口写不好的，后续加功能或者改接口，那就等着加班加点苦逼的去修改吧。同时也耽误了前端或者客户端的开发进度。
- 4.规范的接口可以减少前后端人员为了一个字段在哪一端处理引发的不必要的争吵。
之前我就遇到过明明后台可以处理的比如base64编码，明明可以传一个url给客户端的，非要搞一个base64过来，叫你们自己去解码。后台哥们技术一般，代码又是老项目，它也很多搞不懂，跟他沟通无效，简直是浪费时间，没办法自己去处理吧。
后台java 一定要严格按java编程规范来做，写出规范的接口给别人使用。他好你也好。restful风格的接口的，可以看看这篇文章 转载地址：http://qmeel.baihongyu.com/