未分類
30 10 月 2020

后端不按格式返回数据的问题……

后端不按格式返回数据的问题……

資深大佬 : lwlizhe 6

刚才有个朋友问我，发生什么事了，

我说怎么回事，给我发了几张截图，我一看，

嗷，原来是刚才，有一个高级后端，将业务数据做为 key 返回给我……

（ 咳咳，举个例子：他返回的是直接一个 jsonObject：{“用户名 1″：1，”用户名 2″：2}，我当时还以为是类似于这种：[{“userName”:”用户名 1″，”value”:1},{“userName”:”用户名 2″，”value”:2}] ）

我说可以，我说是不是应该按格式来，这样不好用，

他不服气，我说大佬，你用这种方式返回数据，那怎么转成实体类呢？

我一说他啪就站起来了，很快啊，然后上来就是一句自己解析 json 数据不就行了，

我全部防出去了啊，防出去以后，自然是以商量的语气问下能不能以固定格式的方式，至少能转成实体类，这样大家都舒服，毕竟接口嘛，最好固定格式，这样无论从维护角度还是可用性来说都很不错的

结果他说我是有备而来的，这个只有四年工作经验，还是外包的年轻人不讲武德，来，骗，来，偷袭，他这个高级后端的老同志，这好吗？这不好，他劝我这位年轻人好自为之，好好反思，以后不要再犯这样的错误，小聪明啊，工作要以和为贵，要讲武德，不要搞窝里斗

咳咳，最后当然是以大佬说的为准，毕竟按他的说法

为什么你一定执着于这个非固定 key 这个 jsonobj 和 class 有什么不一样么？

以上纯属根据自身经历而来的逗乐吐槽……如有雷同冒犯，请轻喷~~~~

大佬有話說 (88)

  • 資深大佬 : xuanbg

    如果统一都是这种……写个 map2List 转一下算了罢。为这个吵架没意义，要吵也要拉上技术负责人一起吵。

  • 資深大佬 : xuanbg

    不过我很奇怪，他构造这么一个数据结构难道就不累么？明明用一个集合更直接更方便吧

  • 資深大佬 : ila

    @xuanbg orm 返回的是数组

  • 資深大佬 : comsweetcs

    ….格式能不能拍板好，看得都蛋疼。逻辑也不咋地，废话一堆。

  • 資深大佬 : xuanbg

    @ila 所以我才奇怪呀，把一个集合转成 map 不累么？

  • 資深大佬 : cnbattle

    统一就好……虽然我觉得这样有点不好

  • 資深大佬 : lzlee

    你说他不按格式, 那你的格式从哪里来的

    如果你的依据是文档, 那他就是错了

    如果你的依据不是文档, 那就立马整一个免得以后再扯皮

  • 主 資深大佬 : lwlizhe

    @lzlee 额，没抓住重点……不是文档不文档的问题

    可能是因为排版问题吧，那么省流精简版：

    问题在于：

    他把业务数据当作 key 放到 json 中返回……

    PS：我认为这在任何一个业务、文档中都不该出现……在我看来 json 做为一种键值对数据，如果键值都不明确……那么怎么保证 value 准确稳定呢

  • 主 資深大佬 : lwlizhe

    @comsweetcs 额……这就是盲目套用马保国语录的下场

    看来我玩梗技术还有待提高啊，hhh

  • 資深大佬 : wxsm

    马保国给了你多少钱，我海军学校给双倍

  • 資深大佬 : redtea

    这样的结构有个严重问题，顺序不可控。

  • 資深大佬 : raaaaaar

    文档呢？规范呢？

  • 資深大佬 : watzds

    你说不能处理，那我不敢苟同，是你前端技术不行

    有缺点倒是真的

  • 資深大佬 : watzds

    @lwlizhe 什么叫 json 叫做键值对数据？ json 就是个对象序列化，不一定是键值对

  • 資深大佬 : cmdOptionKana

    如果级比别对方低，不要直接找他理论，肯定说不通的，面子大于技术。应该向自己的上级反映问题。

    如果与对方平级，直接开会定格式，定下来以后按格式办，不用管他是几年经验的大佬。

  • 資深大佬 : debuggerx

    https://www.v2ex.com/t/629474
    https://www.v2ex.com/t/643751

  • 資深大佬 : watzds

    最大问题是用户名如果存在相同会覆盖

  • 資深大佬 : Jooooooooo

    你们的技术方案评审去哪了啊

  • 資深大佬 : xiangyuecn

    对方是老板亲戚，钱还比你多，忍忍吧

  • 資深大佬 : hahasong

    你耗子尾汁吧

  • 資深大佬 : baylee12

    商量着来呗，你这个数据可能是整个对象的一部分。你只要这两个值，他又不想单独再写个 vo 来存储，那就 json 一把梭咯。小公司就这样咯，我一般前端要什么格式，我就给什么格式。和气生财嘛，毕竟摸鱼才是赚钱，写代码是交易。打工人何必为难打工人

  • 資深大佬 : muzuiget

    后端那种可以保证用户名不会重复，你那种能够保持顺序，哪种匹配业务就用哪种，哪有什么标准不标准。

    这种问题也值得吵，说明历练不够，收到数据自己转换一下就完事了，toMap 还是 toList，一行代码的事。

    再说能表示同样信息量的情况下，我站后端，毕竟服务端内存比客户端金贵，再转换一次纯粹多余。

  • 資深大佬 : binux

    @watzds 如果语义就是用户名为 key 那就没问题。

    归根到底这个问题看需求设计，不看你能不能转实体类。
    能不能实现是你的问题，不是设计的问题。

  • 資深大佬 : HongJay

    以后不要犯这种聪明吧

  • 資深大佬 : fansangg

    我记得在贵站发的第一个帖子就是吐槽后端返回数据格式问题的
    https://www.v2ex.com/t/479858
    有兴趣可以看看现在的后端有多水

  • 資深大佬 : billlee

    @lwlizhe #8 你是怎么理解键值对里面的键的？用户名本来就是自然主键，作为键值对里面的键完全没有问题

  • 資深大佬 : baylee12

    @muzuiget 这个不能这么说，毕竟现在前后端都有水货，我遇到过一个前端，vue 自定义 post 表单都不会，他说他们组内规范只有 get 和 post json，能怎么办，改下方法限制咯。我现在就很佛系了，又不是不能用。省下撕逼的时候，摸摸鱼，逛逛论坛，学点自己感兴趣的东西还是挺香的

  • 資深大佬 : baylee12

    @baylee12 时间

  • 主 資深大佬 : lwlizhe

    @billlee 详见 16L 的那俩链接………………我感觉大家都说的很明确了

    简单的来说就是，如果你就给我这个 json，其他什么都不知道

    鬼知道那个用户名是啥玩意……

    key 要明确含义啊……

  • 主 資深大佬 : lwlizhe

    @billlee 对了突然想起来

    如果单独只针对键值对，那肯定是没问题的&……

    但是我说的语境是 json 中的键值对……

    不知道你是不是跟上面一个明确支持把业务数据当 key 值的家伙一样……所以现在回复下，如果你明确表明把业务数据当 key 值的话，当我没回复过……

  • 資深大佬 : syozzz

    他不讲武德啊

  • 資深大佬 : billlee

    @lwlizhe #30 大概理解了，List<Mode> 适合 orm 和页面的映射，Map<Key, Model> 适合计算。我这里后端只管复杂业务的计算，简单的 orm 是 node.js 负责的，所以更多使用的是 Map<Key, Model> 方案。

  • 資深大佬 : sugars

    看到后端问题，我就啪的一下进来了，很快啊

  • 資深大佬 : iApp

    这个我肯定直接就转了,后台返回啥,前端处理啥,懒得扯蛋,浪费时间,又不是做不了

  • 資深大佬 : imdong

    我特别好说话，你给啥，我用啥，你要啥，我给啥。

    只要你不是一天一个样，怎么开心怎么来。

    好说话的咱就商量下，不好说话的咱就当无事发生。

  • 資深大佬 : reus

    传统开发以点到为止？

  • 資深大佬 : Rect

    看得脑壳痛 , 主能不能好好把一件事情讲清楚

  • 資深大佬 : ccppgo

    @imdong 老好人了

  • 資深大佬 : 947211232

    jsonObject：{“用户名 1″：1，”用户名 2″：2}，

    这种很奇葩，如果是单一地方用，双方约定好就得

    如果是全局的话，你还是跟上级反映吧，不利于扩展、维护的

  • 資深大佬 : Kirsk

    别洗 API 就应该以前端友好第一

  • 資深大佬 : EminemW

    不会吧，还有支持用 jsonObject：{“用户名 1″：1，”用户名 2″：2}这种的？该不会方法接收参数还用 map 吧

  • 資深大佬 : smilingsun

    看来 v 站蛮多人不看 b 站不看马保国的

  • 資深大佬 : kooze

    我猜后段是那个最好的语言开发的

  • 資深大佬 : GoLand

    这是小学语文没学好吗。。。。看半天除了主你自己还有谁能看明白你在说什么？发论坛上肯定希望大家一起讨论讨论，写的时候先考虑下是不是大家都能理解你这种火星文。

  • 資深大佬 : labulaka521

    回一句 希望你耗子尾汁

  • 資深大佬 : dustinth

    后端返回这个格式除非是极端要求通信性能的情况(比如返回几千几百个), 都是不合适的: Map 支持不了顺序的语义(返回 List 如果要求顺序呢?), Map 支持单个 entity 的语义上也不清晰(如果返回信息是 getByID 要么返回一个 Entity 要么为空);

  • 主 資深大佬 : lwlizhe

    @GoLand 额，其实问题已经解决了……谁职级高谁说了算……

    其实……我就来吐个槽的~~~~所以写的比较随性哈……见谅见谅，其实具体内容看 append 就行了

  • 資深大佬 : CantSee

    默认用 rest 格式的返回信息 后台就行 int httpstatus;String msg; <T> data; 返回统一 json

  • 資深大佬 : jhdxr

    还是得看场景，如果说是要确保用户名（或者其他作为 key 的字段）唯一的场景下，明显 Map 比 List 合适。

  • 資深大佬 : Orenoid

    我有写过一两次这种接口，不过事先问了前端。因为当时那个接口如果以这种形式返回，只要一两行代码，要转换的话会特别繁琐……我实在不想处理，问了下前端，前端也没意见，就那么返回了。

  • 資深大佬 : danielzh

    据我知道。PHP 这种数据结构简单、且动态解析数据的后端语言，喜欢用这种业务 ID 为 key 的结构。
    （重点：对于 PHP 来说用起来非常方便，像你提到的实体，PHP 涉及很少）
    所以有相当一部分 PHP 后端，认为就应该带 Key 。

    但对于不希望包含太多数据处理逻辑的前端来说，喜欢后者，后者的结构也跟语言相关。
    我之前写 PHP 的时候，会专门写一个数据转换方法，按照前端格式转换一下，对双方都好维护。

  • 資深大佬 : danielzh

    接上文。我从技术的角度分析下，为啥 PHP 喜欢这样。
    1 、后端算出来结果长这样：
    一个数组：[“用户名 1”:1, “用户名 2”: 2]
    2 、调用 PHP 语言的解析为 JSON 对象后：
    {“用户名 1″：1，”用户名 2″：2}
    3 、如果转换成前端期望的结果：
    [{“userName”:”用户名 1″，”value”:1},{“userName”:”用户名 2″，”value”:2}]
    需要将上文的数组，先做一次循环转换才行。所以后端会觉得复杂。

  • 資深大佬 : Ptu2sha

    哈哈 前端很无语 没有 key 不香

  • 資深大佬 : nexo

    耗子尾汁 doge

  • 資深大佬 : xfcy

    我写了好多年 php 也不喜欢这种方式啊

  • 資深大佬 : oppoic

    互相尊重，商量着来。合作几次之后，公司哪个前端最靠谱你肯定心里有数了，再有项目点名要他即可。实在不行自己做前端咯

  • 資深大佬 : bilibilifi

    也就是说计算结果没有对应的 class，那么一些类的特殊限制他都是手动实现而不使用工具链吗？

  • 資深大佬 : ztxcccc

    这帖子我绝对每年看一次

  • 資深大佬 : calmlyman

    看来是训练有素，有备而来啊

  • 資深大佬 : kltt22

    语死早，看起来好费劲。
    @danielzh
    你是怎么知道 PHP 喜欢这样返回的？ PHP 的数据都是[{“userName”:”用户名 1″，”value”:1},{“userName”:”用户名 2″，”value”:2}]这种格式的，PHP 处理数组的方法一箩筐，还搞不定这样的小场面？ PHP 简单易用不是浪得虚名的。反而是 JAVA，做完运算还要筛掉空值的，用 C#对接的时候，没有完整版文档光凭返回值做实体类，不是少这个就是少那个，别扭的要死。

  • 資深大佬 : Exceptionluo

    “我一说他啪就站起来了，很快啊，然后上来就是”

  • 資深大佬 : szuwl

    不会吧，都 0202 年了，还有人后端用 jsonobject 作为返回值对象吗

  • 資深大佬 : oldbaby

    这其实不算不按格式来给数据,真正恶心的是,给的数据不在同一个接口里,前端为了完整的数据,需要同时请求 N 个接口,然后还要 Promise.all 的成功回调才能拼接到完整的数据,后端拿钱不干活,多写一个接口都觉得累,只考虑服务器,不考虑客户端网络请求并行数量,失败率等问题

  • 資深大佬 : NjcyNzMzNDQ3

    来了来了，又一个语言黑。#52

  • 資深大佬 : wangritian

    必须用 array，map 会导致某些语言乱序，比如 go

  • 資深大佬 : danyi

    大 E 了啊

  • 資深大佬 : pph7y

    这种还不如直接返回字符串用分割符号分开

  • 資深大佬 : lychs1998

    array 和 map 返回的最大问题还是在一个 key 的可重复性（不过很少会遇到）和顺序上。如果后端没用有序的 map，则会造成前端乱序。

  • 資深大佬 : withoutconscious

    婷婷呢

  • 資深大佬 : myCupOfTea

    @redtea 是的,顺序不可控,这么干挺那啥的

  • 資深大佬 : qumingkunnan

    格式？谁定的？如果没有定规范就不能说他不按格式来了，定了规范就直接打回去不接收

  • 資深大佬 : bonfy

    其实就是文档嘛，当时接口定义返回这种格式，那人家没错

    如果没文档，那你们继续吵吧，反正模糊地带，解决不了就上升

  • 資深大佬 : PEAL

    这样子写损失了顺序，而且有重复的风险

  • 資深大佬 : rodrick

    老马保国了，首先有咩有没文档，没有的话都是扯皮，其次这种写法确实操蛋，{name:”xiaoming”,age:18}这种写法不是学前后端交互第一节课就该知道的么，但是这人不讲理的话那也没辙，很多事不是技术层面的问题，是人的问题

  • 資深大佬 : yujieyu7

    你的方案更好点，前端也更方便使用。不过，这格式转换前端和后端都是一个 function 解决的事，他听就听，不听就拉倒。出来挣钱嘛，开心最重要，有这撕逼的时间，改都改好了。

  • 資深大佬 : THESDZ

    @yujieyu7 #75 问题在于,大家都是红灯停,绿灯行,你整个绿灯停,红灯行,是没问题,但是不难受吗?

  • 資深大佬 : darknoll

    我遇到这种情况我就会去直接改他的代码，然后久而久之他的代码他可能自己就看不太懂了，就很可能来骂我，然后我就会去揍他

  • 資深大佬 : ElmerZhang

    @kltt22 @danielzh 作为一名写过 10 几年 PHP 的老程序员，我可以证明确实很多用 PHP 的喜欢这样写。
    而且 PHP 还有个函数可以非常方便的把 List 转为这种 Map : array_column
    用法见官方文档 Example 2: https://www.php.net/manual/en/function.array-column.php#example-5378

  • 資深大佬 : goldenCold

    可以说这样你不方便然后让他最好转一下。 没有规范的情况下确实怎么返回都行，没写过前端的后端有时候是会返回一些奇奇怪怪的格式

  • 資深大佬 : coloz

    我遇到更奇葩的是，同一个项目，有些接口是 list 返回，有些是对象返回，项目的管理让几个开发人员自己定，然后大家各写各的风格。

  • 資深大佬 : danielzh

    @ElmerZhang 嗯嗯～ 有一样体会。

  • 資深大佬 : stevenkang

    同后端，只想知道，在代码规范中禁止用 map/json 的情况下，如何写出题主这样的结构

  • 資深大佬 : fengpan567

    又来了，这种帖子

  • 資深大佬 : duxinglangzi

    这特么的 喷他啊， 我作为一个后端都看不下去了 。

  • 資深大佬 : yaoye555

    劝你耗子尾汁,好好说话,别再犯这种聪明,小聪明啊!

  • 資深大佬 : kaiki

    看他返回的这个，我真的想给他一个左正蹬，一个右鞭腿，一个左刺拳。
    这东西拿到手怎么用嘛？

  • 資深大佬 : netnr

    这种格式也是可以的，很符合肉多骨少

  • 資深大佬 : lithium4010

    看场景的，这种数据结构如果用来做基于 用户名 的键值对检索的话效率比较高