Web 技术研究所

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

应该给请求响应更准确的状态码

  昨天的文章中我们想用原生态的throw来抛出错误,这种做法确实在很多编程语言上都同样可行。那在编程语言之外呢?于是我想到了RESTful。虽然这玩意儿在实际场景中不是很管用,但确实给我们提供了一种思想。我们应该更合理地利用原生态的特性。
  在HTTP上,为什么我们总是希望服务器返回的状态码是200而不是别的什么呢?HTTP的200状态码只是表示某个操作成功而已,但很多时候我们的操作是失败的。比如用户提交了非法参数,服务器无法正常执行这个请求,这时候是不是应该使用500代码呢?大多数时候人们都喜欢用200代码,即使返回的数据是一个包含错误信息的JSON。这就和昨天的文章中出现的问题是一样的。并没有一个标准的JSON错误格式,JSON本身并没有错误的概念。只是人们通过基于JSON传输的数据,来自定义了一个描述错误结构体。所以我觉得,对于一些错误操作的HTTP响应,应该用500,或者至少应该用5**的状态码才对。
  也许大家对500状态码的问题并不感冒,因为有时我们可以将逻辑设计到非常合理,甚至只要稍微对URL做下设计都可以符合RESTful。但是还有一些更普遍的问题。比如很多网站在404页面上使用200状态码。看似很操蛋的做法,实际上很多大公司的网站都是如此。




  上面是随便找的几个网站,看404页面的请求。百度和淘宝的设计不仅是404的状态码出问题,这时候使用302临时跳转本身就是一个逻辑问题。既然一个资源是不存在的,这个URL应该被认为不存在,而不该告诉浏览器“这个页面是存在的,只是暂时需要跳转到xxx页面”。QQ和谷歌使用301跳转到等价URL这是正确的做法。但是QQ最后没有返回404的状态码,这就相当于告诉浏览器这个页面是存在的,只是目前的内容就是这些。上面的这些网站中只有谷歌的行为是逻辑上最正确的。
  虽然这样的设计对于用户而言并没有太大影响,因为网页可以正常浏览。但有些时候这些逻辑层面的设计不严谨也会导致一些额外的问题。比如一个爬虫在网站上抓取,如果404页面的状态码都是200,那爬虫就可能会找到大量重复页面,而不是认为这些资源不存在。也许他们还会频繁访问服务器来获取页面的更新。又或者由于网站太多重复内容,直接被搜索引擎K掉。总之这些多多少少对SEO是有一定影响的,虽然一些项目可能可以无视SEO,但就算不为SEO考虑,将来也可能遇上意料之外的问题。我还是建议使用逻辑上正确的设计。
网名:
54.161.77.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^