各位老哥见过这样的后端 API 约定吗

2018-12-04 00:57:52 +08:00
 doommm

入职一个多月,还在试用期,这周被调到一个新的项目组,说是以后就负责这里的前端了。小组就 1 前端+1 后端+1 产品(负责人,也做后端),要做一个统计 项目。

谈到 API 的时候产品告诉我,他们的 API 会返回下面这种格式,我也需要用这种格式返给后端

{
    'A00001': '...',
    'A00002': '...',
    'B00001': '...',
    'C00001': '...',
    // ...
}

ABC 表示数据层级什么的(这个没听明白,好像在数据库里的表字段也是这样命名的),编号随着字段增加会一直递增,会给我一张 Excel 表让我去查对应的编码的解释。

问这么做的原因,说是出于什么加密的打算,说反正前端都是要查表填字段的,变量取什么名字又没差。我:?????

当时我就表示无法接受,气氛一度很尴尬,最后也不了了之了。感觉后面再谈这个事情会闹得不愉快。

这让前端怎么搞?我这一年多经验见识少,有没有老哥能跟我讲讲其中的奥义?

其实还有不少坑,比如原型是一份到处截图下来的像剪贴画的 Excel 表格,月底还要上线第一版,感觉是个巨坑。当时面试的时候并不知道要我来做这个,我都没打算做一个人的项目。

公司 100 人左右,不算太小,感觉算技术型公司,但是要看项目组。做 Web 的前端岗位就我跟面试我的小哥(水平不错)两人,这一个多月是在一起做项目的,配合的很不错,前端这块并不是公司的重点。

现在考虑的是,如果是个坑就得跑,但是因为我是 7 月底离职后在家待了 2 个多月,10 月份才开始找工作并入职的,这样简历上是不是没法看了? 1 年多的前端很多 HR 都直接筛掉了,根本没有面试机会。

坐标厦门,15 毕业,省内 211,工科专业非计算机,毕业后做 2 年 C#开发后转前端做到现在,这是我第一次跳槽,待遇就不要提了,都是泪。

10234 次点击
所在节点    程序员
101 条回复
xi2008wang
2018-12-04 11:49:39 +08:00
@petelin 不需要 hardcode 吧,写一个替换函数,js build 阶段时替换一下
其实这也不是什么加密,就是混淆,加大破解难度
buf1024
2018-12-04 11:53:17 +08:00
@doommm 表示数据层级可能只是一方面,另外,如果所有的 key 都是这样,那么是不是后台对这种 key 有特殊的考虑?比如考虑到以后的扩展,比如分库,数据迁移等,A 开头的,数据迁移的 A 机器,B 开头的数据迁移到 B 数据,这样对以后的数据扩展和分库都比较方便。
xuhaoyangx
2018-12-04 11:54:30 +08:00
说个我知道的...各种宝们和证券交易系统 用的中间件,访问接口也是这样的,数字一串,里面的字段到是比较正常的
doommm
2018-12-04 11:55:49 +08:00
@buf1024 昨天问原因的时候他只含糊的说很多原因,我会再去做沟通
reself
2018-12-04 11:58:04 +08:00
@doommm 可以沟通下一下,只给 Excel 确实坑,这个应该做成后端返回的。至于是首页一次全量返回还是分页按需返回则需要协定。
buf1024
2018-12-04 11:58:15 +08:00
@doommm 这样定义 key 是很正常的,后台的会考虑很多性能和扩展性问题。只是不知道你们是不是这样考虑。
wdv2ly
2018-12-04 12:02:38 +08:00
“如果一个前端项目里面如果充满这些字段名,后续维护迭代成本我是不敢想的”,
多大点事,自己加个跟服务器对接的转换层隔离下不就行了吗
Chingim
2018-12-04 12:07:52 +08:00
无非就是 mapping 谁来做的问题罢了.
这种场景我都是说服后端, 让他们做, 理由:
1. 接口字段应该语义化, 一来方便开发, 需要传什么值一目了然. 二来方便测试, 测试人员抓包的时候如果能一眼看出数据含义, 效率会很高. 不仅仅字段名称语义化, 连字段值也要尽量语言化, 能传 ISO 格式的时间, 就不要传时间戳

2. 如果有多个端(ios/android/其他 web)在消费这个接口, 那么每个端都得做自己做一遍映射, 代码冗余
doommm
2018-12-04 12:20:59 +08:00
@reself 就昨天沟通的结果,字段往多了说还不足 100 个,详细文档还没有给到我。您说的后端给的字段表目前不存在,产品的意思是让我直接往代码里填这些编码。
自己来做 mapping 的工作算是一个方案,我会想想如果要做的话,怎么做的好一些。
有一个新问题是,前后端协商接口的时候,为了不给今后工作挖坑,前端这边需要守住的底线在哪里?
l00t
2018-12-04 12:23:20 +08:00
这是业务需求,你这样理解就行了。傻不傻另当别论,有些看起来很蠢的东西是因为天时地利人和各种原因导致的妥协,有些则是真的蠢。你到这公司才一个多月,还没到可以判断对方业务需求是否合理的时候。

坑不坑什么的,不是这种地方能看出来的。这点鸡毛蒜皮的小事就下定论的话,这世界上怕是也没几个公司不坑了。
xuecan
2018-12-04 12:37:21 +08:00
同厦门呢 难得 哪家公司啊
leexy
2018-12-04 12:53:52 +08:00
你明天不要来上班了
fenglangjuxu
2018-12-04 13:46:40 +08:00
我觉得如果是出于安全考虑,这个无可厚非.比如一些字段名字,定义的见其名就知其意,并不好.
JCZ2MkKb5S8ZX9pq
2018-12-04 13:48:06 +08:00
既然有 excel 了,自己 mapping 一下就好了呗。
先适应公司,再看看有没有改善的可能。
AntiGameZ
2018-12-04 15:28:14 +08:00
@NaiveSimpleYoung mapping 在后端做。mapping 管理有单独的 UI。有意义的文字是给人看的,无意义的字符在 API 层面上用。反正写代码的时候也不会看到这些东西。前端那边在开发阶段使用一样的 mapping,发布的时候 build script 会把这些 mapping 的值做替换。
chenyu8674
2018-12-04 16:25:34 +08:00
sourcecode:var phonenumber=jsonObj.getValue("A00231");

加密,卒
fxxkgw
2018-12-04 17:08:36 +08:00
以前写 C 的吧
TingHaiJamiE
2018-12-04 17:49:55 +08:00
偶然见过一次我们某厂家的代码,里面也是这样写的,理由和楼主说的一样,为了保密
sammo
2018-12-04 22:01:46 +08:00
编程 是不是典型的 “一个东西有很多种实现的办法”
在某种限制条件之下,才会过滤得出一种办法
而人们又无法对 “某种限制条件” 达成共识
感觉就是 这根本就没法整
感觉就是 很容易造成权威崇拜,最后发现 权威也不权威
生命如此懵懂
( 珍爱生命、远离编程 )
519718366
2019-01-04 11:10:14 +08:00
我一个做过社保项目的同学当时也跟我吐槽过,就是你这种设计字段设计,貌似是 zf 的尿性?🤷‍♂️

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/514030

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX