V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
AppxLite
V2EX  ›  程序员

某些后端不知道是因为太懒还是因为其他原因,对于 json 的数据处理表示很崩溃

  •  
  •   AppxLite · 2020-02-11 15:38:38 +08:00 · 8742 次点击
    这是一个创建于 1756 天前的主题,其中的信息可能已经有所发展或是发生改变。

    首先,命名一踏糊涂,比如某些订单列表数据 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。

    各位前端小伙伴们,遇到这样的接口,你是怎么处理的?

    75 条回复    2020-02-13 09:00:03 +08:00
    back0893
        1
    back0893  
       2020-02-11 15:42:04 +08:00   ❤️ 1
    哦.后端应该是 php 吧.叫 php 处理下,因为 php 里面的数组不会去区分 list 和 array 的差别
    symeonchen
        2
    symeonchen  
       2020-02-11 15:51:34 +08:00   ❤️ 6
    与同事协商,协商无果找领导,
    与领导沟通,沟通无效换工作。
    jugelizi
        3
    jugelizi  
       2020-02-11 15:54:17 +08:00
    哈哈
    又黑我大 phper 确实 php 在序列化 空对象和有数据的不一样 [] 和 {}
    saucew
        4
    saucew  
       2020-02-11 16:04:18 +08:00
    我猜你们的后端是 php
    learnshare
        5
    learnshare  
       2020-02-11 16:04:41 +08:00
    a_list 直接开除吧,或者你辞职吧
    loopback
        6
    loopback  
       2020-02-11 16:18:19 +08:00
    碧池配狗,天长地久😂
    huntcool001
        7
    huntcool001  
       2020-02-11 16:20:21 +08:00
    这是你们技术部门管理的问题...
    imnpc
        8
    imnpc  
       2020-02-11 16:21:48 +08:00
    这个看起来后端是 PHP,确实有些处理方法不太一样,需要沟通下
    cmdOptionKana
        9
    cmdOptionKana  
       2020-02-11 16:23:14 +08:00
    你们不开会的吗,会议上摊开来当面说个明白。
    imdavidyang
        10
    imdavidyang  
       2020-02-11 16:25:30 +08:00
    不是某些后端,是你们的后端,规范建设不严。
    这种事情在对接接口时不沟通好需要打板子,当时不据理力争自己也得挨上 20 板子
    pastgift
        11
    pastgift  
       2020-02-11 16:27:53 +08:00 via iPhone
    和是不是后端没关系,就是水平差,让他写前端搞不定会要求后端一个页面一个接口呢
    cpdyj0
        12
    cpdyj0  
       2020-02-11 16:30:47 +08:00
    后端是不是不熟悉自己用的这个技术栈,感觉是序列化反序列化的锅,肯定不会是 Java 系的
    Cbdy
        13
    Cbdy  
       2020-02-11 16:33:36 +08:00
    后端换 Node,JS 一把梭,天下太平
    cpdyj0
        14
    cpdyj0  
       2020-02-11 16:38:23 +08:00
    前后端一起换 Kotlin 吧,后端上 Kotlin/Native Kotlin/JVM 前端上 Kotlin/js (x
    Alexhohom
        15
    Alexhohom  
       2020-02-11 16:39:35 +08:00
    最后两个没问题吧,没数据和有数据的 json 就应该是这样
    ben1024
        16
    ben1024  
       2020-02-11 16:42:44 +08:00
    加一个数据输出层过滤解决这种输出类型无约束情况
    ccraohng
        17
    ccraohng  
       2020-02-11 16:50:20 +08:00 via iPhone
    我猜你们后端是 php
    garlics
        18
    garlics  
       2020-02-11 16:53:19 +08:00
    最后的只要不是同一个接口,问题就不大吧。a_list 这个就是水平问题了。
    AppxLite
        19
    AppxLite  
    OP
       2020-02-11 16:56:37 +08:00
    @Alexhohom
    @garlics 就是同一接口才有这个问题,后面的例子看后面三条对比
    rioshikelong121
        20
    rioshikelong121  
       2020-02-11 16:58:16 +08:00
    沟通 不行自己加中间层转化。
    Philippa
        21
    Philippa  
       2020-02-11 16:58:27 +08:00 via iPhone
    @Cbdy 哈哈哈哈哈 JS 统治世界万物
    mcfog
        22
    mcfog  
       2020-02-11 16:59:20 +08:00 via Android
    怎么说呢,你要发帖吐槽这个,至少先搞清楚 markdown 语法,还有你自己的... list 这个 token 的语义
    现在这样看上去感觉就是五十步笑百步
    Philippa
        23
    Philippa  
       2020-02-11 16:59:56 +08:00 via iPhone
    提交接口时打回去,或者说用强类型协议,比如 graphql
    luozic
        24
    luozic  
       2020-02-11 17:00:44 +08:00
    规范啊,不规范的 json,公共 prase 库认么?
    Juicpt
        25
    Juicpt  
       2020-02-11 17:04:40 +08:00   ❤️ 1
    hhhh 看我这个,中文编程 hhhh 内心毫无波动
    dilu
        26
    dilu  
       2020-02-11 17:11:45 +08:00
    php 的确会这样 只能说规范一开始就没做好
    跟语言无关 跟人有关
    一般我都会跟客户端或者前端提前确认结构,怎么互相方便怎么来。
    5bb864e1fc775087
        27
    5bb864e1fc775087  
       2020-02-11 17:22:32 +08:00   ❤️ 1
    接口返回格式已经确定是 code msg data 这 3 种
    这两个接口要怎么处理比较好?
    a 接口:
    {
    "code": 200,
    "msg": "ok",
    "data": {
    xxx: true,
    yyy: 123,
    zzz: "zzz",
    }
    }

    b 接口:
    {
    "code": 200,
    "msg": "ok",
    "data": [
    'xxx',
    'yyy',
    'zzz',
    ]
    }
    sytnishizuiai
        28
    sytnishizuiai  
       2020-02-11 17:29:27 +08:00
    我也是 phper,之前做前后分离也碰到过,无论我给的 json 还是接收的 json 格式,我先写 api,如果前端处理不了或者不规范,我这直接统一改,很快的,即使需要改成很奇怪的格式来适应某个功能,我们前端还是外包靠微信交流的。(有时候他方便就他改了)

    所以这是开发人员个人问题和交流问题了。
    exploreXin
        29
    exploreXin  
       2020-02-11 17:29:56 +08:00   ❤️ 3
    都在说后端谁谁谁怎么怎么样,是有人代码不规范,但这不是造成问题的的主要原因,真正原因是团队代码质量体系没跟上,每次代码写完有代码审查制度吗,没有时间代码审查,团队总该有个代码规范约束大伙吧,没有代码规范,开会的时候临时沟通下总该有吧,要是都没有,那代码质量不高也就不奇怪了。写这种水平不高的代码,有的人是懒,不负责任,而有的人是因为上家公司就是这么写的,现在还是这么写,并且现在的公司也没人把这事提出来当做紧要事情处理一下,一个制度完美的团队,应该是就算是 0 基础 0 规范的开发进到团队里面,也可以通过短时间跟上团队的规章制度,按照规范来工作,只是现实中大多都是创业小公司,能活下来就不错了,根本没有时间与精力去搞那些领导眼里“没用”的事情,要什么规范,能赚钱才是王道,两个后端给的东西都兼容不了,给你那么高工资干啥用的,如果遇到这种领导的公司环境,这个基本无解,秉持要么忍要么滚的原则,反正我遇到这种一般都是自己滚的,钱哪里都可以挣,但是技术水平,技术习惯这种个东西随着年月增长,是不可逆的,失去的时间不可能再追回来了,所以与其在不规范团队混日子拿工资,不如去个规范的团队,工资少拿一点也没什么。
    fxxwor99LVHTing
        30
    fxxwor99LVHTing  
       2020-02-11 17:34:38 +08:00
    这很明显后端有问题啊,和技术大佬反馈。
    charlie21
        31
    charlie21  
       2020-02-11 17:36:38 +08:00
    所以接受哪些方面的教育才可以避免此类错误呢?
    mdesi
        32
    mdesi  
       2020-02-11 17:50:19 +08:00
    找技术领导反馈问题啊
    CYKun
        33
    CYKun  
       2020-02-11 18:00:24 +08:00
    @Juicpt #25 简单明了,我觉得没毛病
    orzorzorzorz
        34
    orzorzorzorz  
       2020-02-11 18:08:31 +08:00
    如果只是命名不舒服,可以让公司大佬加个 schema,专门用来对应字段的中文名。
    ck65
        35
    ck65  
       2020-02-11 18:11:33 +08:00
    Tech Lead 有最终决定权,而且应该为这类设计负责。让他 /她知道你们的问题先。
    fewok
        36
    fewok  
       2020-02-11 18:24:06 +08:00
    这种槽吐的,真没深度。
    mengzhuo
        37
    mengzhuo  
       2020-02-11 19:59:27 +08:00
    一看就是 PHP 的锅哈哈哈
    jokeqf
        38
    jokeqf  
       2020-02-11 20:05:19 +08:00
    人不行怪语言,真逗。就跟国足踢得不好怪教练一样。
    springz
        39
    springz  
       2020-02-11 20:14:03 +08:00
    @Juicpt 我看了 5 分钟,实在想不出来应该怎么解析这个格式。
    springz
        40
    springz  
       2020-02-11 20:15:11 +08:00
    曾经有一段时间,我拿到后端奇怪的 JSON,刚工作,不敢喷,自己默默的在入口写正则处理成正常 JSON。
    springz
        41
    springz  
       2020-02-11 20:16:24 +08:00
    多年 PHPer,多年 Javaer,说句公道话,大部分 PHP 程序员可能真的是不知道其他语言程序员会骂娘。
    springz
        42
    springz  
       2020-02-11 20:21:15 +08:00
    @jokeqf 的确怪不到语言,大部分 PHPer 认知是真的浅。
    springz
        43
    springz  
       2020-02-11 20:21:44 +08:00
    技术栈太单一,array 打天下。
    ZXCDFGTYU
        44
    ZXCDFGTYU  
       2020-02-11 21:09:30 +08:00
    跟领导说就是了,没有必要一杆子打死人。我之前也不知道,后来公司的技术总监教给我的,告诉我这么做方便其他语言的同事开发。4 年 phper。
    DelayNoMay
        45
    DelayNoMay  
       2020-02-11 21:18:04 +08:00
    你作为前端,我觉得你应该先了解下你对接的后端语言,简单了解即可,就不会有这么大反应了
    p1gd0g
        46
    p1gd0g  
       2020-02-11 21:58:48 +08:00
    项目组一直用 proto,没有遇到过类似的问题。
    iiji86
        47
    iiji86  
       2020-02-11 22:00:57 +08:00 via iPhone
    @Juicpt 要是不要求排序感觉也挺好,连接口文档都不需要就能看懂所有字段的意义,还不用费脑子想英文 ze 翻译
    wangyzj
        48
    wangyzj  
       2020-02-11 22:12:15 +08:00
    这不是语言的问题了
    这是没规定好规则的问题
    springz
        49
    springz  
       2020-02-11 22:46:36 +08:00
    @iiji86 不用 PHP,用 Java 不能用反射,或者 C++ 或者 Go,你试试解一个这个 JSON。
    springz
        50
    springz  
       2020-02-11 22:51:14 +08:00
    中国这么多城市,你全写实体类试试。
    a852695
        51
    a852695  
       2020-02-11 23:02:29 +08:00
    基本上每个月都会有这种帖子,我建议还是请你同事一定要认真看看《 HTTP 权威指南》,只需要读前半部分就应该懂 HTTP 协议,这些滥用明显就是对 HTTP 都不懂,拿着半截就开始跑,说的不好听,这种人基础太差了,你和他讲道理是讲不通的,而且你作为前端,一定要强势,因为前端才懂需求,你直接告诉他:不能做就辞职。
    815979670
        52
    815979670  
       2020-02-12 06:34:33 +08:00
    PHP 确实不分这个 但是因为后台的前端部分是我写的 所以 我 json_encode 的时候 会注意这个
    sampeng
        53
    sampeng  
       2020-02-12 07:49:02 +08:00 via iPhone
    这种返回结果你还不怼?心真大
    kim01
        54
    kim01  
       2020-02-12 09:27:26 +08:00
    别说其他的,高德地图之前的接口都有这个问题。。。。
    Juicpt
        55
    Juicpt  
       2020-02-12 09:27:27 +08:00
    @CYKun #33 确实简单明了。。。。
    @springz #39。。。。只能说我幸好是前端。。。就直接 Object.keys(value)一通遍历取出来就好。。。。。
    @iiji86 #47 给前端确实好一些。。。。
    killerv
        56
    killerv  
       2020-02-12 09:30:55 +08:00
    所以,很多垃圾 PHP 程序员拉低了 PHP 这门语言
    xman99
        57
    xman99  
       2020-02-12 09:49:52 +08:00
    希望你们可以规范起来。 如果是返回单个对象,要求返回单个对象的, 我觉得完全没问题
    多个数据返回数组,这样要求没问题。如果奇奇怪怪返回的,请主管协调一下吧
    keepeye
        58
    keepeye  
       2020-02-12 10:27:46 +08:00
    该后端可能是北大青鸟出来的?
    codelegant
        59
    codelegant  
       2020-02-12 10:59:22 +08:00
    不要浪费时间在 v2 上发帖,直接去工位上喷。
    KyonLi
        60
    KyonLi  
       2020-02-12 11:17:51 +08:00 via iPhone
    习惯了,现在不对接口请求进行封装,写好一个请求到处粘贴再根据实际情况修改,能用就好技术追求不能当饭吃
    HanMeiM
        61
    HanMeiM  
       2020-02-12 11:20:25 +08:00
    所以,很多垃圾 PHP 程序员拉低了 PHP 这门语言 +1
    gz911122
        62
    gz911122  
       2020-02-12 11:41:44 +08:00
    我猜你们的后端是 php
    zakokun
        63
    zakokun  
       2020-02-12 11:59:08 +08:00
    怎么又在骂 php 了...码农经常自称逻辑严谨,结果一个个都这么狭隘的
    说白了,这就是你们团队有问题,前端,后端,移动端一个个都不是无辜的,一个都跑不掉。不可能后端一坨屎,前端都是白莲花,就从后端能出这种接口,你们前端包括 leader 既然没开会沟通定规范,前端移动端也好不到哪去啊
    xmge
        64
    xmge  
       2020-02-12 12:36:14 +08:00
    确实,这种格式对前端很不友好。

    感觉后端做成这样也得刻意写个方法处理下。
    xmge
        65
    xmge  
       2020-02-12 12:36:30 +08:00
    总结:你和他有矛盾吗?
    loshine1992
        66
    loshine1992  
       2020-02-12 12:45:08 +08:00
    我们后端 PHP 也出了一下子返回 {} 一下子返回 [] 的问题

    弄得我头都大了。。
    ljhaoboy
        67
    ljhaoboy  
       2020-02-12 13:56:45 +08:00 via iPhone
    我想到了饿了么的签到😂,签到没奖励的时候返回的[],有奖励的时候就是 json
    wangbenjun5
        68
    wangbenjun5  
       2020-02-12 14:02:24 +08:00
    只说一个 PHP 可能会遇到的问题就是一会 {} 一会 [],让 PHP 特殊处理一下把空数组转成 object 就能解决,其它都是规范问题,前后端交互如果没有规范那是很头疼的事情,多点沟通吧!
    xmge
        69
    xmge  
       2020-02-12 14:37:46 +08:00
    @ljhaoboy []也是一个 json 啊。
    veike
        70
    veike  
       2020-02-12 17:47:00 +08:00
    路由就不说了,自己的问题,和 php 没关系。
    返回的数据问题:
    当只返回一条数据的时候:
    data:[] 就变成了 data:{},这里返回的是该条数据。例如:后端是:["ok" => 1],前端:{"ok":1},如果为空,就是[]。如果放在数组里,就是[{}],前端返回和后端一样。

    当返回多条数据,data 就是 data:[{},{}],在后端就是:
    [
    ["foo1" => "bar1"],
    ["foo2" => "bar2"]
    ],
    到了前端就是:
    [
    {
    "foo1" => "bar1"
    },
    ...
    ]

    然后如果分页的话,一般是,后端
    [
    "last_page":2,
    data:[
    {},
    ....
    ]
    ]

    这些就是自己处理的,你要和后端说一下。
    然后返回的数据要统一处理一下。可以这样,

    json_encode([],JSON_FORCE_OBJECT | JSON_PRETTY_PRINT | JSON_UNESCAPED_UNICODE)

    这样在前端返回的都是 object。
    hallDrawnel
        71
    hallDrawnel  
       2020-02-12 18:25:50 +08:00
    List 就该是 List,kv 就该是 kv,跟他说不清楚就向上汇报。
    back0893
        72
    back0893  
       2020-02-12 19:56:21 +08:00
    就是后端的问题
    应该是直接拼的返回值
    因为 php 里面的 list 和 dict 不区分导致的,叫后端处理下就完事
    php01
        73
    php01  
       2020-02-12 20:15:59 +08:00
    是人的问题,大家别怪到后端的问题上,也不要怪到 php 的头上了。
    如果你们后端不知道怎么做,告诉你们的后端,new \stdClass() 就是一个空对象了,确实是要几行代码的。
    melvin
        74
    melvin  
       2020-02-12 21:07:53 +08:00
    如果我们后端也这样提供,我也得骂他丫的,这种谁顶得住
    yeqiaowei321
        75
    yeqiaowei321  
       2020-02-13 09:00:03 +08:00
    @Juicpt 哈哈哈哈,太秀了
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5318 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 01:18 · PVG 09:18 · LAX 17:18 · JFK 20:18
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.