两个后台提供的接口对比

[androidBrant]

之前一个项目：外包的，接口数据json返回，不管接口要查询几张表，所有的数据全在data键下，这样结果是，两个表有相同名字的字段，另一个就重命名了，不跟数据库保持一致，而且数据全在一起，不好区分。想像一下，一个接口里uid,tid,mid,...一堆的id

现在一个项目：招了一个几年的后台，接口数据还是json返回的，data键下面，不同表的数据都有一个单独的键（以表名命名），返回的数据清晰，解析代码也清楚，调用各表对应的实体类的解析方法一下就搞定了。

写代码还是得要水平，还有外包真的是坑死人。page从0开始也就算了，各种怎么简单怎么设计，不考虑后面的开发。

还有很多坑爹的地方没写，外包真的是太坑，想做东西还是不要找外包了。

[androidBrant]

{
data = (
{
address = "\U4e2d\U56fd\U9ed1\U9f99\U6c5f\U7701\U5927\U5e86\U5e02\U8087\U5dde\U53bf\U671d\U9633\U4e61";
"by_user_id" = 0;
"by_user_id_avatar" = "http://test.tianmijie.com/public/avatar/000/00/00/00virtual_avatar_middle.jpg";
"card_share" = "\U5179\U5b9a\U4e8e\".to_date($val['wedding_time'],\"Y\U5e74m\U6708d\U65e5\").\"\U4e3e\U529e\".$val['man'].\"\U548c\".$val['woman'].\"\U7684\U5a5a\U793c\Uff0c\U656c\U9080\U60a8\U5149\U4e34\U3002\U70b9\U51fb\U67e5\U770b\U8bf7\U5e16\U8be6\U60c5\Uff1a\".$wedding[$key]['card_url'].\"
\n////////
\n\U5179\U5b9a\U4e8e2014\U5e7408\U670828\U65e5\U4e3e\U529e\U54c8\U54c8\U548c\U5475\U5475\U7684\U5a5a\U793c\Uff0c\U656c\U9080\U60a8\U5149\U4e34\U3002\U70b9\U51fb\U67e5\U770b\U8bf7\U5e16\U8be6\U60c5\Uff1ahttp://test.tianmijie.com/xitie/?BAN7Y";
"card_url" = "http://test.tianmijie.com/xitie/?BAN7Y";
content = "look \U5566";
"create_time" = 1408958039;
"fav_count" = 0;
hotel = "\U54af\U6478\U4e86";
id = 185;
img = "http://test.tianmijie.com/public/wed/201408/fdc8ad6c97fd7bfa7b971dff71e247bf44_200x0.jpg";
"img_angle" = "";
"img_card" = "";
"img_multiple" = "";
"img_v" = "http://test.tianmijie.com//public/wed/201408/76dfa172d6bce5888f08f70292c74ae063_200x0.jpg";
"img_video" = "/public/wed/201408/76dfa172d6bce5888f08f70292c74ae063.jpg";
"img_xpoint" = "";
"img_ypoint" = "";
"invite_code" = BAN7Y;
"invite_img" = "http://qr.liantu.com/api.php?text=BAN7Y";
"is_delete" = 0;
"is_effect" = "-1";
"is_frend" = 0;
"is_img" = 0;
"is_info" = 0;
"is_photo" = 0;
"is_private" = 0;
"is_tpl" = 0;
"is_video" = 1;
man = "\U54c8\U54c8";
"man_avatar" = "";
"message_count" = 0;
"o_path" = "http://test.tianmijie.com//public/wed/201408/fdc8ad6c97fd7bfa7b971dff71e247bf44.jpg";
"photo_count" = 1;
"share_count" = 0;
tel = "";
"template_id" = 1;
title = "";
"user_id" = 52;
"user_id_avatar" = "http://test.tianmijie.com/public/avatar/000/00/00/52virtual_avatar_middle.jpg";
"v_path" = "http://test.tianmijie.com//public/wed/201408/20140825173126.mp4";
video = "/public/wed/201408/20140825173126.mp4";
"vip_count" = 1;
"wedding_time" = 1409217180;
woman = "\U5475\U5475";
"women_avatar" = "";
xpoint = "0.000000";
ypoint = "0.000000";
}
);
page = {
page = 0;
size = 1;
total = 1;
};
status = 1;
}


看到最后面的status我又想到了一个，吗B的，数据为空status给我返回0

[androidBrant]

{
"status": 1,
"data": {
"count": 6,
"event": [
{
"Event": {
"name": "asdf\u8fd9\u662f\u4e00\u4e2a\u6d4b\u8bd5\u6d3b\u52a8239",
"cover": "http:\/\/www.baidu.com\/img\/bdlogo.png",
"cate": "1",
"id": "47",
"cate_name": "hello"
},
"Member": {
"uid": "",
"nickname": ""
},
"Elog": {
"id": "",
"praise_num": "",
"negative_num": "",
"view_num": "",
"collect_num": "",
"attention_num": "",
"share_num": ""
}
},
{
"Event": {
"name": "asdf\u8fd9\u662f\u4e00\u4e2a\u6d4b\u8bd5\u6d3b\u52a8264",
"cover": "http:\/\/www.baidu.com\/img\/bdlogo.png",
"cate": "1",
"id": "48",
"cate_name": "hello"
},
"Member": {
"uid": "",
"nickname": ""
},
"Elog": {
"id": "",
"praise_num": "",
"negative_num": "",
"view_num": "",
"collect_num": "",
"attention_num": "",
"share_num": ""
}
}

]
}
}

对比一下

[hcymk2]

当初外包的时候，你们怎么和外包那边定义接口的json字段的？难道不是双方先协商下。

[androidBrant]

@hcymk2 我是新来的，半路接手这个iOS开发。我会说前后端都是外包的吗

[binux]

视业务需求，mysql 连表查询字段可不是混在一起的吗？
page 从 0 开始也要抱怨。。没有约定，从 0 开始又没什么不对，反而是很正常的。

[xylophone21]

@androidBrant

前端后端都是外包的,也可以约定接口.

这种东西,要么每个程序员都溢价,靠高水平程序员自我管理;
要么专人审核,单点提供溢价

指望它自己好起来,基本很难.

[raptor]

第一，接口没有定义好是你们自己的问题，既然前后端都是外包，两个外包方自己协商好即可
第二，在接口中直接暴露表结构不是好办法

[cdffh]

不认为 为了图方便在接口中暴露表结构是什么好事情。。

[androidBrant]

@raptor
@cdffh

在接口中分表返回有啥弊端，我做iOS的不是很清楚？还有一般接口都是返回需要的字段，也不是全部字段，这也是内部开发才知道，别人就是截到了数据也是猜这是啥。

[raptor]

@androidBrant 一个是安全性问题，不要低估互联网世界的险恶。另一个是没必要，正因为移动端需要的不是所有字段，同样它也不需要服务端的结构，而是应该根据移动端的需要定义自己的结构，服务端把数据组织成移动端需要的结构返回，所以，当然也不是像原来外包做的那样把所有字段放成一个平坦的结构，而是应该做成一个层次化的对象结构。