RESTful 没有一个标准范式，只有各大厂商的实践规范，所以也谈不上遵守。

在成功的响应中加 code 和 message 字段在我看在是无意义行为，只是为了方便调用者使用统一结构进行解析的偷懒行为。
但 data 字段在某些情况是需要在在成功的响应中返回的，因为 oc 不支持解析数组形式的 json 数据...不知道现在是否支持了，除此之外也没有什么必要加 data 字段。

至于 http status code 是否能够代表业务状态，在我看来是不能代表的，它最好只代表 http 请求的状态。因为在客户端提交请求的过程中，各个组件（代理、网关等）都是根据 http status code 来对请求进行处理。

在响应错误时，如果有额外的 message 字段来对错误进行描述，或者增加 code 字段来代表某一类 message，这都是业务需要，与 RESTful 无关。

早买早享受
去年没等到，今年继续等买一赠一的续费活动

这里的主要问题应该是将字段的校验放在了值对象的 New 方法中，可以把它剥离出来，像现有的一些库一样，把规则写在 tag 上，然后统一验证。

@baiyi #2 补充一点，我看的一本关于 RESTful API 的书里吐槽过这个解释，因为这个 “data-handling process” 含义太过模糊，所以现在有人的接口设计为全用 POST，其实也是符合 HTTP 语义的，因为任何操作都能引申为数据处理......

在 URL 的设计上我觉得能够语义清晰就可以了。

“获取支持的数据源类型列表” 我认为两种设计都可以，甚至 `GET /data-source?filter=types` 这样也可以，都是表达只获取 types 。

但 “提供连接参数，检测数据源是否可用” 我认为不应该用 POST 方法，ping 这种行为在我看来应该是安全且幂等的，应该用 GET 方法。所以这里合适的设计应该是 “GET /ping-data-source”

在我看来你的思考矛盾主要在于：你认为 HTTP Methods 都是针对资源的操作，而这个资源又被局限于实体存在的资源。
但这个资源实际上可以是抽象的、动态的，比如说用 RESTful 风格设计最常见的问题就是 “登录” 这个接口如何设计。其实只需要 `POST /login` 就可以。从 HTTP POST 方法本身的语义讲，是完全支持这样做的，它并不是单纯的用于创建资源的语义。rfc 文档中关于 POST 能力的部分解释：“Providing a block of data, such as the fields entered into an HTML form, to a data-handling process;”

支持容器的 paas 平台应该都可以，比如 heroku： https://devcenter.heroku.com/articles/build-docker-images-heroku-yml

参加过 Go 夜读的读书会，可惜愿意一起讨论分享的人不多。

@iannil #8 完全不吃肉吗？会不会有些肉类中的微量元素没有摄取到，有点像素食者。

@czfy #6 哦哦，明白了。游戏引擎在做这方面的模块，他们提供周边的服务模块。所以以后游戏开发确实会越来越简单。

@czfy #4 他们（ TDS ）现在抽象出了社区、好友、成就、存储、数据分析、广告这几个模块。并没有涉及到游戏根本的内容上。我想以后会不会出现根据游戏类型的相关模块化。比如 FPS 游戏提供枪支模型动作，赛车游戏提供车辆模型碰撞什么的。

加入了“ TapTap 的开发者服务（ TDS ）”，搜了一下是那种模块化的游戏开发工具。有没有相关从业人士讲讲这种东西好用吗？以后做游戏真的能拖拖模块组合起来就可以吗

这也太按照字面的意思来理解了。

我理解的 devops 是一套由各种原则、方法组成的工作体系，由此来达成提高产品质量、保证安全性、快速交付等目的。

看过一个 TEDx 的演讲，是关于努力的，演讲者有一句话我认为讲得很好，一直牢牢记着。

《我们这一代人的困惑--于宙》
“这些年我一直提醒自己一件事情，千万不要自己感动自己。大部分人看似的努力，不过是愚蠢导致的。什么熬夜看书到天亮，连续几天只睡几小时，多久没放假了，如果这些东西也值得夸耀，那么富士康流水线上任何一个人都比你努力多了。人难免天生有自怜的情绪，唯有时刻保持清醒，才能看清真正的价值在哪里”

努力是为了实现梦想，或是达成目的。向着错误方向的努力，也是努力，只不过是愚蠢导致的，这种努力也是没有价值的。

以此来看 A 和 B ； A 如果是向着错误的方向努力，其实不过是自我安慰罢了。B 的问题我觉得在于应该要求自己，而不是要求别人，如果以是否成功来否定别人的努力，对于别人来说，未免太过残忍。毕竟成功不仅仅只能靠努力，就算向着正确的方向努力，也不一定能成功。

可以看一看心理学相关的书，它们可以帮助你更好的接受、更有勇气改变。

别看精神分析学这种治病的，要看更“鸡汤”一点的个体心理学和积极心理学。上面也有人提到过的《被讨厌的勇气》和《哈佛幸福课》。

Go 由于有自己的调度模型，所以它的 channel 阻塞不是依赖于线程的。而是由 Go 自己的运行时来保存 goroutine 的上下文，然后等待唤醒。

线程的并发可以看看 CSAPP 的第十二章 并发编程

@monsterxx03 #8 我觉得 Go 的运行时调度模型实现的挺好的，一个 go 关键字就能用。但毕竟没有暴露底层的线程操作，所以碰到这种情况只能通过 cgo 实现。