最近在给某个组设计一套基于 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 时代的遗产。如果前后端分离,我实在想不到有什么用这个状态码的必要。