Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

「操作成功」的 200 与 204 之纠结

  当我们请求删除或更新一条数据时通常并没有需要响应的具体数据,这时候响应 200 或 204 状态码都可以。既然可选,那么有选择综合症的我又得开始纠结了,这时候到底该用 200 还是 204 状态码呢?现在我们从 200 状态码开始,一路纠结下去,纠结到海枯石烂吧!

真没什么好响应的

  其实「操作成功」也不是什么数据都没有的,如果真有数据我们就使用 200 响应所需的数据,这是最正常的逻辑。但现在我们主要纠结的是无数据可响应的情况。在完全没有数据需要响应时怎么办?

从 200 状态码开始

  没数据也可以响应 200 状态码嘛,只是 Content-Length 为 0 而已。那么问题来了,在 Content-Length 为 0 时,Content-Type 应该取什么值?这个问题有点类似 CSS 中空值的单位问题,CSS 中我们可能在空值时省略单位。但是 HTTP 上 Content-Type 就算省略也会被作为 application/octet-stream 来解析。所以还是得提供硬着头皮提供一个 Content-Type。

纠结到 Content-Type

  考虑到 API 通信统一使用 JSON 格式,所以响应的 Content-Type 也应该是 application/json 吧?那么问题又来了,JSON 不允许空串,必须有数据才算是合法的 JSON。也就是说 Content-Length 不能为 0,否则不是一个合法的 JSON。那么我们又要调整 Content-Length 的值,并且在响应的数据中添加一个人畜无害的标准 JSON 格式。于是最终出现了这样诡异的响应结果: HTTP/1.1 200 OK
Content-Length: 2
Content-Type: application/json
......

{}

这不是蛋疼嘛?

纠结到彼岸

  为嘛纠结 200 状态,直接来个 204 多好,不再纠结任何 Content-* 头,有数据的时候 200,没数据的时候 204。这么简单的事情我居然纠结了这么久。呵呵,我真是已经没药救了。

网名:
3.80.55.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^