在 Go 入门中曾明确写 SliceHeader 的三部分, 但没有提 StringHeader.

不说深究 Go 的运行时了, 把所有官方包好好看看就足够对 Go 提升认识了. (当然还要有空翻翻标准)

我身已死, 漏洞长存.

https://zsqk.github.io/news/2020-07-17-github-arctic-code.html

虽然对于这种人造的, 有历史的东西, 争论没有意义. 但我觉得在这个过程中, 我们能对什么是更好的有更多的理解. 我们的讨论都是在表述自己的理解, 不存在说服谁的问题.

以下都是我的想法, 不是客观正确的, 是我认为正确的. 不是要说服谁, 是想表达让大家参考, 也期待大家有相关的分享让我参考. 讨论的目的只是互通有无.

## 关于是否使用 REST

首先, 如果不用 REST, 进入业务后都返回 200 是一种我可以接受的设计. 这点我觉得没有问题. 我的个人经验是, 交互业务重时, REST 捉襟见肘.

## 关于什么是 HTTP Client

但当我作为前端时, 我可能更希望大家去使用 HTTP 状态码而不是不去用. 因为我这个前端不认为 4xx 错误码是给前端代码用的, 而是给用户的. Client 可能表示前端代码, 浏览器, 用户. 前端也是 user agent, 和浏览器一样, client 应该主要代表 user, 而不是 user agent.

## 是否要用 HTTP 状态码

基于与 HTTP Client 的想法, 所以我倾向于 API 使用更多的 HTTP 状态码.

## 关于 REST 最初设计的想法 (暂存草稿)

https://v2ex.com/t/689938?p=1#r_9251862

> The key abstraction of information in REST is a resource.

- HTTP 协议有状态码设计.

> Although those implementations reflect many of the design constraints of REST, having been developed by people familiar with the Web's architectural design and rationale, the real WWW architecture is independent of any single implementation. The modern Web is defined by its standard interfaces and protocols, not how those interfaces and protocols are implemented in a given piece of software.

- REST 存在一些设计约束, 这些设计约束来源于当时的 WWW 实现(比如 libwww, 在现在我已经不知道这是个什么东西了, 应该类似于 HTTP 服务端与浏览器的结合吧).
- WWW 是独立的, 不受制于任何软件设计实现, REST 也是一种利用 WWW 实现业务的设计实现, 不应该被排除, 大家可以考虑考虑.

不是说 REST 多好多好, 大家都该用.

而是主题问的是 REST, 所以就这个来回答不跑题.

1. REST 到底好不好用, 这个见仁见智, 但较为老旧简单难以适应复杂需求这点可能更多人认同.
2. HTTP 状态码到底怎么用, 我认为还是要看情况吧, 所有业务一旦进入处理流程都 200 太绝对了.

@libook

不是纠结一定要 REST, 而是认为 HTTP 状态码在一些地方应该被使用.

Web 最初是为了描述网页资源.

如果一个文章网页曾经存在, 但因为一些原因被删除了.

客户端是浏览器.

这时后端返回 404 是不是更好一些?

---

再说 API.

如果请求 `GET /item?id=123`, 数据库中没这一数据, 这时候状态返回 200, 再给数据不存在的业务代码是合理的.

但是如果请求 `GET /item/123`, 数据库中没这一数据, 我认为这时候状态返回 404 而不是 200 才是合适的.

具体用哪种风格好, 我不评论. 只是主题说了 "RESTful 的增删改查成功应该返回什么状态码?", 而不是 "API 的增删改查成功应该返回什么状态码?", 所以主题说的应该是上例中的后者.

如果把 HTTP 状态码当作后端错误代码的分类, 这样似乎就很好理解.

我是不建议弃用 HTTP 状态码, 只用 200 的.

@libook

- 需要告诉客户端它犯了个（请求的资源不存在的）错误
- 这个资源不存在

我觉得这两个难以区分.

我认为我理解你想要表达的, 就是协议统统 200, 不需要 404, 除非 API 路由都不对, 才会 404.

但这种设计不符合 RESTful, 这里不是说 RESTful 绝对正确, 而是不符合 RESTful.

在用小新 Pro 13, 黑苹果还是有些问题, 比如

1. Clover 可能间歇性出现花屏, 重启可解决. (感觉大概 5% 概率)
2. 还有休眠耗电(不同 SSD 耗电不同, 西数 SN750 8 小时掉电 20%).
3. 蓝牙在(假)休眠之后可能出现无法使用的情况, 重启可解决. (感觉大概 5% 概率)

我这里使用 Intel Power Gadget CPU 不插电功耗 15W, 插电后也不超过 20W. 我没看到别人反映过这样的问题, 但我实测是这样. 可能是驱动问题?

如果没有白苹果, 我觉得用一个路由器连接到网卡上就行.

如果之前就是苹果, handoff 可能的确离不开.

iPhone + iPad + iMac + MacBook Pro

iMessage 真的是沟通利器.

家人沟通都是 iMessage + FaceTime.

没流量的时候用微信视频.

工作用钉钉.

最近刚入手紫米 65W. 也是看了一大堆评测.

笔记本的话, 联想口红还是首选. 温度低, 电压有富余.

但紫米也不算太差, 便宜三十块, 就入了紫米.

GaN 因为做的比较轻便, 好像目前都热.

@iugo 是的. 如果家在晋城, 回来也是一种选择.

就像 996 拿 30k 累了, 换个 965 20k 或许时薪还更高点.

京东京造 K6, 就是 Keychron K6, 国内买现在只要 349, 可以入.

有山西晋城的咱们聊聊呗?

官方文档给的建议挺清楚了:

```
<button onClick={handleClick}>
</button>
```

https://reactjs.org/docs/handling-events.html

当时下雨, 打车是打不到的, 只能等公交.