sin30 最近的时间轴更新
sin30

sin30

V2EX 第 46144 号会员,加入于 2013-09-29 09:43:58 +08:00
sin30 最近回复了
122 天前
回复了 showB1 创建的主题 程序员 规则引擎推荐
2022-07-29 12:22:16 +08:00
回复了 roseduan 创建的主题 程序员 程序员不应该和一门语言绑定在一起
我觉得你说的还不够。

程序员不仅不应该和一门语言绑定在一起,也不能和某个公司绑定在一起(比如大公司),还不能和某项业务绑定在一起(比如电商、直播),甚至不能和技术绑定在一起(要产品、销售、运营全都行)。要和时代的运势绑定在一起,和宇宙大道绑定在一次?我还是俗了,应该超脱无界,不和任何事物绑定在一起。

有追求是好的,把自己逼死就没意思了,一辈子才能吃几顿饭,开心快乐不重要么?
2019-07-04 18:36:38 +08:00
回复了 springmarker 创建的主题 程序员 在微服务中是用队列好还是 RPC 好
我理解强依赖的调用关系,肯定是要走 RPC,并且明确获得返回结果的情况下才能继续的。
那些弱依赖的,类似只是通知一下其他服务做动作的,可以做成队列异步执行的,确保最终一致就行。
但是这个界限还是比较模糊的,理论上是可以把所有对外的调用都做成队列消息,异步让其他服务处理,不过这样的话设计起来就会复杂很多,你得定义多少消息类型,异步任务啊。
2019-07-04 12:41:54 +08:00
回复了 lihongjie0209 创建的主题 程序员 前后端分离的情况下表单重复提交的解决方案思考
如果你这个后端的 API 不仅仅是给前端提供服务的,还可以给第三方提供服务,通过他们的后端程序来进行调用。
这时针对 PUT, POST 的重复性校验就是个累赘,因为免不齐就有一些接口是要批量被调用去更新的,POST 接口本身就不是幂等的,你这么一做,硬是搞成几秒钟之内的重复调用被后端给拦截掉了。
到时候你还得写个白名单,某些接口可以允许不拦截。
2019-07-04 12:38:12 +08:00
回复了 lihongjie0209 创建的主题 程序员 前后端分离的情况下表单重复提交的解决方案思考
我觉得这个表单重复提交的问题还应该放在更大的尺度上去看,而不仅仅是前端和后端的交互上面。
2019-07-01 11:26:10 +08:00
回复了 zuoakang 创建的主题 程序员 Restful API 资源未找到应该返回什么状态码?
@broadliyn 我们可以针对你发明的接口规范来和 RESTful 建议进行一些有意义的讨论,来评判到底谁的设计规范更好用,更规范。
2019-07-01 11:23:58 +08:00
回复了 zuoakang 创建的主题 程序员 Restful API 资源未找到应该返回什么状态码?
@broadliyn 在你发出自己发明的接口规范之前,我不会对你的回复进行任何无意义的评论。
2019-07-01 11:16:42 +08:00
回复了 zuoakang 创建的主题 程序员 Restful API 资源未找到应该返回什么状态码?
@broadliyn 这里确实没有 RESTful 的规范标准,所以我也是说 RESTful 风格或者建议。RESTful 只是建议大家把 HTTP 标准更好的用起来。

每个公司确实会根据自己的偏好选择某些来实现,规避某些实现,这也是现实存在的,但是你只拿人家做的不好的来说,这就有点偏颇了。

对于 RESTful 的基本共识大家还是有的,各种开发框架也把这些共识固化下来给大家用了,可以参考 SpringMVC。

只要是有利于接口表达、使用者方便的好技术、好建议我都支持。

请看清楚本贴的题目,人家问的是 RESTful API,你可以随便写 http 接口,但请不要说自己是 RESTful。

另外既然你知道 RESTful 别家公司用的那么烂,有勇气晒一下自己发明的接口规范么?

看看你不用 Accept 头是怎么做 Content Negotiation 的,不用 Accept-Language 是怎么做多语言国际化的。
2019-07-01 10:59:59 +08:00
回复了 zuoakang 创建的主题 程序员 Restful API 资源未找到应该返回什么状态码?
@broadliyn 首先感谢你写这么多。
2019-06-29 10:45:41 +08:00
回复了 zuoakang 创建的主题 程序员 Restful API 资源未找到应该返回什么状态码?
本来这种帖子都是懒得回复的,看懂 HTTP 协议,RESTful 建议和国外各种 api 设计的人,不会问出这种傻问题的。

但是好奇心让我看完了所有的回复,截止发送此回复时,共有 29 个回复支持使用 404,39 个回复支持用 200。

看来还是 200 党获胜啊。

这些 200 党,请问你们仔细研究过 HTTP 协议,看懂理解 RESTful 的思想,读过 Github 的 API 接口么?

都 9012 年了,还有那么多抱残守缺、不思改变的人,也真是 shame 啊。

从最开始写 API,就知道用 200,用 get post,写了这么多年不想想有没有更好的方式么?

这还只是个 200 和 404 的争论,恐怕 200 党肯定也不允许 URL 里面出现 id 参数,不允许使用 put patch delete 吧?
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1397 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 13ms · UTC 17:26 · PVG 01:26 · LAX 10:26 · JFK 13:26
Developed with CodeLauncher
♥ Do have faith in what you're doing.