后端设计调整 / 失业的第 17 天

2022-07-07 · 周四郁闷小雨

昨晚和 @GZ 同学聊了很晚,回家洗洗睡就已经三点多,于是乎又睡到了中午。我那金山的同学还是咬咬牙去上班了,还表示她全部搞定了。因为小米那下单就可以直接选闪送,她的新手机 11 点多就到手了,少了一次拿“好人卡”的机会...

我选择去了 KFC 吃午饭,带了笔记本电脑,毕竟能白嫖空调,还有插座充电。选了个 30 左右的三件套套餐,比麦当劳什么的都要贵,但能品尝下别的风味也好吧==(不过这个插座估计使用次数太多了,里面的铜片特别松,我换了好几个姿势反复尝试,用纸巾垫着才勉勉强强插了进去)

饭后基本上就在继续优化着小窝后端的代码,还是此前 namespace 那个问题,修好之后给一个点赞表做了独立的模型层(原先在“通用函数”里面,有些奇怪),此前已经独立了「媒体」和「媒体分类」两个功能的模型层和接口,所以小窝后台也需要增加和修改对应的管理页面。

简单测试将代码发布到生产之后,我发现有一个很致命的问题,就是模型层如果根据某个条件获取到了不存在的的数据,将会返回 NULL,触发了强类型判断的异常,因为格式化函数(此前命名叫 filter,理论上叫 formatter 更好?这个命名模仿的 Vue 过滤器)接受的仅 Array

这个问题可能比较傻,但我晚上还是问了下 @Eric,如果接口获取的数据内容是不存在的,后端要怎么返回比较好,返回 nullfalse 还是空对象?

他说最好不要返回任何东西,返回 null 或者 false 这种情况是最容易找打的。因此最好的办法就是不进行返回,然后把 HTTP 状态码改成 404,标记成“不存在的东西”。如果是分页接口,可以返回 [] 空数组,也能强调这是一个“分页接口”。客户端只要检查到状态码不对就可以绕开设置数据的逻辑,自然也就不会有问题了。

我感觉他这个设计很中规中矩、合情合理,按照这样的设计思路,格式化器的类型限制还是维持原状,模型层如果获取不到数据直接返回 false 给控制器,控制器检查到没有数据后返回 404,就完美解决了!

IMG_2541
Life

Life

Roa
Paul

Paul

特立独行的一只前端菜狗。这篇日记编写大概耗时了 0 分钟,内容均为个人原创,并采用 CC BY-NC-SA 4.0 授权协议,转载请注明来源,谢谢!如本站内容对你有所帮助的话,不妨 捐助支持 一下?

近期评论

鲍小螺: 前辈多多指教!ahu: 后生可畏寻梦xunm: 真不错,板子很好看。timochan: 太惨了( ,更新暴毙,如果恢复没成功,数据也 dump 不出来鲍小螺: 在这部分对话中,广树和保罗继续讨论生活的不同方面。保罗提到了技术更新和国内的优秀 IT 技术。广树解释了在国内积累的经验如何在日本产生穿越的感觉,并表达了对于日本生活节奏的喜爱。他还提到了医疗水平的差异和对于生活方式的感受。保罗表示,通过动漫和现实的对比,艺术来源于现实,日本生活的确有着独特之处。他们讨论了国内的生活节奏和就医等方面的压力,以及个人选择的自由。最后,他们也谈到了不结婚不买房的选择和对于房价的困扰。鲍小螺: 该对话进一步讨论了房地产和税收的问题。保罗提到了国内的房地产税和增值税以及日本的固定资产税。广树解释了日本房地产税的收取方式,以及房产税对于国内房产的影响。他认为,与国内相比,日本的房子质量和服务更好。保罗提出疑问,为什么自己拥有的地也要交税。广树解释了类似增值税的原理,并指出在日本拥有房产是稳定安全的。最后,保罗表示从广树的角度来看,情况确实是如此。鲍小螺: 这篇文章的聊天记录也尝试过用 GPT 总结,结果并不是太好,不知道是不是 Prompt 的问题,实际出来的内容过于简练了,于是又耗费了半小时写完,呼~
奇趣音乐盒技术源于 Kico Player
Emmm,这里是歌词君