随便谈谈 HTTP 的 201 204 205 状态码

最近在给某个组设计一套基于 REST 的接口规范，重温了一遍 HTTP 的状态码，然后发现了几个很有点模糊的状态码，稍微想了想，略有所得，就拿出来随便谈谈。

其实纠结 HTTP 状态码的含义是很有点学院派的意思的，就我的观察，大部分人成功就是 200，出了错就是 500，顶多自己封装一个返回值，加点报错信息啥的；而且在大型组织里很可能还会有组织内的自定义错误码，直接结果就是弱化了 HTTP 状态码的语义：反正我只需要知道调用是否成功，自然会有其他信息来具体描述调用过程。

自定义错误码倒还好，封装返回值其实就有点臃肿了，而且无形中增加了调用方的负担，因为如果在消息体里定义详细的状态码，那仅凭调用结果是很难直接判断下一步应该执行的操作的，必须进一步解析消息体，而且有些调用其实并不需要返回值，为了统一返回值，还是要加一些类似于OK、success这种的不必要的返回值。事实上，HTTP 状态码具有很丰富的语义，并且是一个标准的规范，完全可以节省一些不必要的信息传输。

到这里都是废话。

---

201 Created：请求成功，创建了一个新的资源

• 一般是 POST 请求成功之后返回，主要是为了表示创建了一个新的实体。
• 个人认为在 PUT 创建新实体时也可以用这个。

204 No Content：请求成功，不需要返回实体，而是在消息头中返回发生变更的元信息。

• 这是比较抽象的说法。根据这个描述，可以在 PUT 更新实体时返回这个，并且在请求头中标明哪些字段发生了变化。
• 但是他的本义是“没有内容”，所以如果 GET 请求查到的内容是 null 时似乎也可以返回这个。
• DELETE 请求成功后也可以使用这个，因为确实不需要返回内容。

205 Reset Content：请求成功后重置

• 整体行为比较类似于 204，比如输入之后清空表单，为了方便输入，这是规范上的原话。但是规范上同时提到一点，重置的是 document view，而不是 form，不知道为什么以讹传讹就变成了重置表单。
• 但我感觉比较奇怪的一点是，服务端为什么需要对客户端的行为提出请求？我个人觉得可能只有在发送敏感信息的时候才会用到这个状态码，为了避免信息泄露，但其实用着也有点别扭，更不用说那种列表展示实体，然后点击删除导致需要更新展示的列表，用这个就更牵强了，毕竟接口的实现者也不可能预料展示页面的实现，他也不知道要不要刷新页面。
• 应该是 MVC 时代的遗产。如果前后端分离，我实在想不到有什么用这个状态码的必要。