V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  Muninn  ›  全部回复第 20 页 / 共 89 页
回复总数  1761
1 ... 16  17  18  19  20  21  22  23  24  25 ... 89  
2019-03-17 11:29:38 +08:00
回复了 thisisgpy 创建的主题 云计算 预告一下,明晚 7 点腾讯云有 2C8G5M3Y 的神机
各位,我这几天没看,到底有没有 2C8G5M3Y 1400 多的?

我看到一个要快 3000,只是 2 折。

要是还有 1 折的考虑再抢一个。

明早 9 点那个上海的 3 年不知道怎么样。
2019-03-15 11:19:34 +08:00
回复了 meetocean 创建的主题 分享创造 历时 2 年多亏损 50 万,就这点作品,大家看值不值?
挺有想法的……造一个网文中的大芬村……

不过这价值观还是和我不太一样的。

感觉这世上有两类工具,有的工具是为了让人更方便的创造……有的工具会让人更高效的创造垃圾。

当然两类工具到底怎么界定,还没想清楚。就像今日头条和微信公众号的区别吧。
2019-03-11 15:37:56 +08:00
回复了 thisisgpy 创建的主题 云计算 预告一下,明晚 7 点腾讯云有 2C8G5M3Y 的神机
那个确实太便宜了,去年撸了两个。明天要忍住。两个够玩了。
师兄的思路应该是可行的

导师说的没看出来。本科论文是不是只需要写一篇思路加 demo,不用实现啊……

传播路径的话,微信是取不到的。

微博能取到但是很难。

媒体之间互相抄能取到但是也很难,需要买到或者自己爬到一定时间的媒体资讯。

有的谣言传播时间很长可以和爆炸新闻区别开来。但是有的新谣言光传播路径真的很难区别特征。

这个用传播路径的思路真的是太难了,怎么都感觉导师应该外行瞎想的。
还是要看中介,如果是小中介,多半是黑中介。。。还存在个被骚扰的问题。

但是在法律上,合同一般写的是甲方要毁约,和乙方协商一致后,可以赔偿违约金并解除合同。

法律上只要乙方不想解除合同,没人能解除。
买不破租稳赢,只要你仔细看你的合同没啥问题。
小米的就完了…… 你可以设置不点别亮……

国外的同步起来都超级慢
2019-02-28 20:17:19 +08:00
回复了 jaycee110905 创建的主题 Go 编程语言 请教 Beego 的一个问题!
这个跟 beego 没关系……在填充结构体前,先 make([]string,0) 别等 orm 帮你 make。
2019-02-28 09:39:38 +08:00
回复了 xelnagaga 创建的主题 问与答 域名后缀.app 和.io 哪个好?
不知道是一个比较小的程序,还是微信小程序。
微信小程序的话,必须备案。。。
2019-02-27 11:56:33 +08:00
回复了 zrcgege 创建的主题 硬件 设计申请了一台这样的电脑,大家觉得合适吗
不专业,设计电脑可以这么贵,但是不是这么配的。。。
呃 看了这么多 其实没那么麻烦的,直接往信用卡部门寄房本车本复印件就可以了。。。如果不是同一个银行发公司,寄工资流水也有用。
总之信用卡的问题去 飞客茶馆 搜搜旧帖子都能找到答案
现在应该好点了。 招行的评分系统一直在升级。

我毕业申请的,后面七八年都是三千。。。

这几年用中信了,它才给我嗖嗖的提。
2019-02-23 21:42:12 +08:00
回复了 Muninn 创建的主题 编程 RESTful API 中的 Status code 是否要遵守规范
@xfriday 额外信息放在 Header 中也是个流派,但是这不是 Resp Body 的替代品。

首先,一般开发中图片都用的对象存储+CDN。

好,我们来考虑自己生成非文本对象的情况。

其实在 Response Body 中放 Error 结构体本质上就是正确返回和错误返回是不同的结构体,在客户端也会进入不同的处理流程。所以这跟正常结果是 JSON 还是 Object 没关系,错误了始终是一个错误结构体。

反而是全 200 流,一般才把错误放在 Resp body 中,导致如果正常返回不是一个 JSON 就没办法做了……
你又找到了一个全 200 流的缺陷。
2019-02-23 21:26:41 +08:00
回复了 Muninn 创建的主题 编程 RESTful API 中的 Status code 是否要遵守规范
@vibbow 哈哈这是怨念有多深
2019-02-23 09:37:11 +08:00
回复了 Muninn 创建的主题 编程 RESTful API 中的 Status code 是否要遵守规范
@AlisaDestiny 可以看看我帖子中 “我的建议”章节。

然后 paypal 和 microsoft 之类的 API 规范里也有类似的处理方案。
2019-02-22 16:53:43 +08:00
回复了 Muninn 创建的主题 编程 RESTful API 中的 Status code 是否要遵守规范
@rayhy 看“我的建议” 那一节。

只要是错误,一定要自定义一个统一的错误结构体。可以返回第二级的 error code (可以是数字或者字符串),和 message。

我贴的微软的链接和下边有人贴的 paypal 的链接,也可以参考。不过有些过于复杂了,属于特别理想化的错误返回。
我和那些理想化的规范的核心不同是,我只考虑返回单个错误,而他们考虑了返回多个错误的情况。

多个错误又有链式的过程中出现的错误和列表处理中出现的并列错误两种情况。

实际上太复杂了为写程序造成负担,还是只返回一个最直接的错误好操作一些。
2019-02-22 14:41:20 +08:00
回复了 Muninn 创建的主题 编程 RESTful API 中的 Status code 是否要遵守规范
@passerbytiny 同意你说的前半部分,ID 找不到的确有很多种可能。 这块因为因为这篇文章的知乎问题描述的很清楚,数据库里没有这条数据。所以这种情况下应该是 404 的。

否则根据情况可能是 400 401 403 404 410 都有可能。

但是你对于 500 的认识或许可以再去研究一下。500 的含义是表明这是一个未曾预料的问题。只有程序出 bug 了异常没有被处理,或者处理过程未预料的中断比如读数据库出错了的这些情况才会出现的。一个好的服务是不应该出现 500 的,出现了就可以肯定是服务方的错:)

场景二你描述的其实比较模糊,有可能是你觉的如果 id 是你提供的,客户端的请求肯定是对的,所以在程序里觉得如果找不到肯定是出现了未预料的状况,好了我认怂抛出个 500,要是出现了前端会找我,我再查查 bug。
但其实不存在这种状况的,因为 RESTful 你是不可控客户端的呀,说不定是前端同学拼 id 拼错了呢,调试的时候一看 500,锅直接就抛给你了。。。
2019-02-22 12:08:40 +08:00
回复了 Muninn 创建的主题 编程 RESTful API 中的 Status code 是否要遵守规范
@WilliamYang
@casillasyi
@huangdayu
@relaxgo

感谢各位的支持,看来 V2 还是倾向于尽量遵守规范的比较多。
2019-02-22 12:06:51 +08:00
回复了 Muninn 创建的主题 编程 RESTful API 中的 Status code 是否要遵守规范
@mcfog RESTful 是基于 HTTP 通讯协议的一种数据交互风格,

我们讨论的是要不要遵守 `HTTP 协议规范` ,不是 RESTful 的规范。你连这个省略都看不懂,后边还说了这么多……
1 ... 16  17  18  19  20  21  22  23  24  25 ... 89  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   5082 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 53ms · UTC 01:23 · PVG 09:23 · LAX 17:23 · JFK 20:23
♥ Do have faith in what you're doing.