@domodomo #11 https://www.parallels.cn/ 这个可以吗

有希望，最近两年都不抢了，每次都候补，人数少的时候多人数中的时候也有，每次都在发车前两三天候补到。

我觉得应该引入一个值得信任的第三方，否则很难从技术层面解决问题，在技术是掌握在某一方手中的情况下

初学者 《 Go 语言圣经》要看，但不用看完之后立刻看 《 Go 语言高级编程》，里面讲的 CGO 、汇编等内容我觉得不是刚上手的人想看的，翻翻第一章倒是可以

如果主写 go，个人体验 goland 比 vscode 要好用，我就是从 vscode 转到的 goland

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;”