首先,命名一踏糊涂,比如某些订单列表数据 A、B、C。
../api/a
{
"code": 200,
"msg": "ok",
"a_list": {
...list
}
}
../api/b
{
"code": 200,
"msg": "ok",
"b_list": {
...list
}
}
../api/c
{
"code": 200,
"msg": "ok",
"c_list": {
...list
}
}
因为这三个 api 接口用的都是相同的页面和布局,就因为这种脑残的 list 命名,前端会为此作出特殊的处理。
再举个例子:不知道某些后端对 json 是不是有什么误会,json 的数组和对象都分不清(在他们眼里,json 的对象和数组都是数组),这不是最恶心的,更恶心的是,同一个 api 接口同一个值,在不同的情况下,给你返回不同的数据类型。比如:
同一个接口:../api/data
某些情况是这样的:
{
"code": 200,
"msg": "ok",
"data": {
...list
}
}
某些情况又是这样的:
```json
{
"code": 200,
"msg": "ok",
"data": []
}
再举个例子,明明不是数组,但是却要用[]来包一层,比如:
已知这个 data 的数据结构永远不是一个数组的。
```json
{
"code": 200,
"msg": "ok",
"data": [{
...list
}]
}
再举个例子,当只有一条数据的时候,是这样的:
{
"code": 200,
"msg": "ok",
"data": {
...list
}
}
当没有数据的时候是这样的
{
"code": 200,
"msg": "ok",
"data": []
}
当有一条以上的时候又是这样的:
{
"code": 200,
"msg": "ok",
"data": [{
...list
}]
}
这些后端不知道是因为懒,还是因为自己的认知有限,每次和这样恶心的接口对接,作为一个前端的人来说,看到这样的接口,就像吃屎一样。和他们沟通不但不认同,还各种推脱说{}就是数组。。。
各位看官,你们觉得这是不是小题大做了?虽然通过各种处理,这些问题都不算啥,但是为何可以通过常识来解决的事,为何不把规则当规则呢?你用 json,就要遵循 json 的规则。而不是这就是 XXX。
各位前端小伙伴们,遇到这样的接口,你是怎么处理的?
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.