Web 技术研究所

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

REST API 设计之 —— 跨域问题

  跨域这个坑在前几个月的文章中曾大量踩过,当时还稍微总结了一下这些坑,后来又掉进了 IE8 的坑里。最后给出的方案是以前分享过前端 API Proxy 方案。绕了这么一大圈,仔细想想也许并不是因为跨域坑多,而是为何非要跨域?如果 API 设计时就不跨域不是很好么?
  API Proxy 方案虽然可以解决 IE8+ 的 API 跨域问题,但这个方案很绕。而且从名字看吧,Proxy?不就是代理嘛?为何非要让前端来坐代理不可?后端代理显然要更容易实现嘛。而且代理甚至不需要程序支持,稍微修改服务器配置,搞个反向代理就能实现,为什么还要把这么艰难的工作丢给前端?
  于是我终于想通了,不跨域,我们不跨域!虽然反向代理本身也有点服务器开销,但我觉得比起前端搞一套麻烦的 API Proxy 方案来破坏逻辑完备性,这点服务器开销其实也没什么。

  具体的做法可以在使用 API 时,将请求发到当前域的某个目录下(比如 /api 目录)。服务器配置中将这个目录接收到的请求转发到真正的 API 服务器上。很多情况下,HTTP 服务器和 API 服务器根本就是在同一个机房,它们是局域网级的连接速度,所以理论上从 HTTP 服务器到 API 服务器的传输开销可以忽略不计。
  这个设计是不是有点太理想化了?确实总是会存在一些必须跨域的情况,比如 API 是单独的服务器,和 HTTP 服务器是不在一起的。那么这时候就要考虑这套 API 设计出来后要兼容的浏览器版本。现代浏览器的话,完全没问题,CORS 上就行,最多也就多出个 OPTIONS 请求而已,至少功能是可以实现的。但如果要考虑 IE8 就得退一步用 API Proxy,它可以在不破坏 REST 概念的情况下支持 IE8。又或者要兼容到更低版本的 IE,那就得用更低级的方法 JSONP 上。
  总之,我建议的方案优先级是:不跨域 > CORS > API Proxy > JSONP
网名:
34.203.245.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^