V2EX › iseki 的所有回复 › 第 22 页 / 共 46 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 18 19 20 21 22 23 24 25 26 27 ... 46

❮

❯

2022-12-03 23:23:11 +08:00

回复了 edis0n0 创建的主题 › 程序员 › API 不管操作成功还是失败都返回 200 状态码，自己在返回结果里又定义一个表示是否成功的属性是从哪里传开的坏习惯？

我也支持以 2XX 表示成功，以 4XX/5XX 表示失败，并在失败时内部包含业务用错误码的做法。这样的好处主要是不侵入响应体，可以兼容响应体是 JSON 以外内容的情况，同时也极大规避多态反序列化

2022-12-03 23:20:48 +08:00

早期的时候状态码非 2xx 会被篡改，同时没有传输层安全，所以衍生出了这种怪用法。现在很多人改不了，有些前端、后端因为自身水平问题竟然会告诉你不是 200 的就没法统一封装······然后他们还觉得他们这种统一封装的方法挺好，所以就这样了呗（直到现在在某些特殊的场景还会存在 200 劫持行为···）

2022-12-03 13:08:07 +08:00

回复了 hi20151215x 创建的主题 › 信息安全 › 请教各位下将用户的 id 在 jwt 中算是敏感信息么？

不要把 user id 当隐私信息，id 这种东西保不齐什么地方就露出去了，不要依赖它保证安全性

2022-12-03 13:03:50 +08:00

回复了 yusheng88 创建的主题 › 程序员 › 关于 jwt 做认证，有些疑问

看一看 Linux 的 keyring 机制？不管是不是 jwt ，凭据存储都是个问题，我看大多都无所谓了，直接往哪一丢谁爱看谁看了…

2022-11-26 11:30:05 +08:00

回复了 hhhhhh123 创建的主题 › 程序员 › 高并发下怎么做余额扣减？

如果是扣库存，只要保证别 100 个商品，结果 10000 个请求打到数据库上、也别同一时间点 100 个请求全都在数据库上扣同一个商品，就没什么可担心的，数据库的性能足够。
扣余额就更简单了，限制下不要让一个用户同时发起一堆请求（这本来也该限制吧）
实现上可以用 update cas ，但存在限制不方便时直接 Serializable 性能不一定差（ PostgreSQL ）

2022-11-18 01:45:11 +08:00

回复了 qiyong 创建的主题 › 程序员 › 面试中遇到的一道 sql 题

@DinnyXu 这种需要全表扫来扫去的 SQL 一般都不会经常跑，也就是个定时任务，一个小时刷一遍排行榜之类的

2022-11-17 23:52:45 +08:00

回复了 qiyong 创建的主题 › 程序员 › 面试中遇到的一道 sql 题

个人不倾向这里用开窗，题目中感觉并没有明确提出开窗统计的需求，更多的其实是就是把多个统计维度的数据攒到一块了，那 with 几下感觉更好一点

2022-11-17 23:34:26 +08:00

回复了 qiyong 创建的主题 › 程序员 › 面试中遇到的一道 sql 题

@DinnyXu 如果性能敏感，以至于需要给其中的部分子查询增加额外的缓存，那才会选择拆开；否则这种简单查询直接一个 SQL 是最优解，不管是性能上还是功能上。

2022-11-17 23:26:33 +08:00

回复了 movq 创建的主题 › 程序员 › 为什么 Java 父类构造函数调用被重写的方法会调用到子类的

@movq 其实父类子类本来就搅合在一起了，不差构造函数这一点吧