买不破租稳赢，只要你仔细看你的合同没啥问题。

小米的就完了…… 你可以设置不点别亮……

国外的同步起来都超级慢

这个跟 beego 没关系……在填充结构体前，先 make([]string,0) 别等 orm 帮你 make。

不知道是一个比较小的程序，还是微信小程序。
微信小程序的话，必须备案。。。

不专业，设计电脑可以这么贵，但是不是这么配的。。。

呃 看了这么多 其实没那么麻烦的，直接往信用卡部门寄房本车本复印件就可以了。。。如果不是同一个银行发公司，寄工资流水也有用。

总之信用卡的问题去 飞客茶馆 搜搜旧帖子都能找到答案

现在应该好点了。 招行的评分系统一直在升级。

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

这几年用中信了，它才给我嗖嗖的提。

@xfriday 额外信息放在 Header 中也是个流派，但是这不是 Resp Body 的替代品。

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

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

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

反而是全 200 流，一般才把错误放在 Resp body 中，导致如果正常返回不是一个 JSON 就没办法做了……
你又找到了一个全 200 流的缺陷。

@vibbow 哈哈这是怨念有多深

@AlisaDestiny 可以看看我帖子中 “我的建议”章节。

然后 paypal 和 microsoft 之类的 API 规范里也有类似的处理方案。

@rayhy 看“我的建议” 那一节。

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

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

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

实际上太复杂了为写程序造成负担，还是只返回一个最直接的错误好操作一些。

@passerbytiny 同意你说的前半部分，ID 找不到的确有很多种可能。 这块因为因为这篇文章的知乎问题描述的很清楚，数据库里没有这条数据。所以这种情况下应该是 404 的。

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

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

场景二你描述的其实比较模糊，有可能是你觉的如果 id 是你提供的，客户端的请求肯定是对的，所以在程序里觉得如果找不到肯定是出现了未预料的状况，好了我认怂抛出个 500，要是出现了前端会找我，我再查查 bug。
但其实不存在这种状况的，因为 RESTful 你是不可控客户端的呀，说不定是前端同学拼 id 拼错了呢，调试的时候一看 500，锅直接就抛给你了。。。

@WilliamYang
@casillasyi
@huangdayu
@relaxgo

感谢各位的支持，看来 V2 还是倾向于尽量遵守规范的比较多。

@mcfog RESTful 是基于 HTTP 通讯协议的一种数据交互风格，

我们讨论的是要不要遵守 `HTTP 协议规范` ，不是 RESTful 的规范。你连这个省略都看不懂，后边还说了这么多……

好的背景音乐也有生产力加成哦

小程序还不能付费去广告。。。因为是虚拟支付，你得在其他渠道让人付费。。

一般是优先引导关注公众号再想办法盈利。

@0myun 9 万

你有本事用一个注册资本 10 万的公司欠债 1e，那你真是有本事。