Web 技术研究所

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

为什么有时候用 POST 去做 GET 的事情?

  我们通常认为,如果需求只是获取一个数据,并且是安全且幂等的,根据 REST 的理念应该用 GET 方法来完成。理论上这么做是非常合理的,但理论终究是理论,实际应用中对于接口使用的方法我们还要考虑数据的获取成本。对于数据获取成本高的接口即便安全幂等也不能 GET。
  我觉得,所有 GET 接口都是很容易被挂载在 CSRF 上的 DDoS。比如到一个超高流量的地方发一张图片,图片的 src 写上某个 URL,那么这个 URL 就会被瞬间大量请求。这就是挂载在 CSRF 上的 DDoS,比起传统 DDoS,它几乎是没有成本的,只是它能够攻击的仅仅是 GET 接口而已。对于 POST 请求通常是用户通过某些操作产生的,而且现代浏览器还有同源策略问题,很难被 CSRF。
  如果一个 GET 接口会大量消耗服务器的 CPU 或 IO,那么这样的接口被 DDoS 就让服务器资源耗尽,造成其它接口响应超时。如果一个 GET 接口是依赖另一个异步服务的结果,而这个等待时间可能很长,那么 DDoS 以后请求就会堆积,造成正常请求无法处理。
  所以说,GET 方法即便是无状态也要考虑对服务器性能的开销,如果一个 API 是非常耗资源的(无论是 CPU、磁盘 IO 还是内存甚至带宽)那它就不应该被设计成 GET 方法。
  当然,一些 REST 脑残粉估计无法接受获取列表 count 这样的接口被设计成 POST。但实际上在 MySQL 的 InnoDB 中,对大表的 count 操作是一个慢成狗的事情。总之以上就是我的观点,不服也不要找我撕逼。
网名:
23.20.64.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^