那么,JSONP还是CORS?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (14)

我的WebAPI部署在Intranet环境中。这意味着安全并不是我关心的问题。

CORS似乎对客户更友好更易于实施

我可能错过了任何其他担忧?

提问于
用户回答回答于

这是一个相当宽泛的问题,可以保证维基本身。谷歌在这两方面也有相当一部分,但我想我可以打出几个关键点。

  • 如果服务器需要只读ajax接口,并且需要支持IE <= 9,Opera <12或Firefox <3.5或各种其他较老或隐蔽的浏览器,则CORS不在使用JSONP。IE8和IE9 sorta支持CORS但有问题,请参阅下面第一条评论中的链接。
  • 另一方面,如果Web API是读取/写入(例如完整的REST或只是POST / GET)而不是只读(即GET),那么JSONP就没有了。使用CORS。JSONP本质上是只读的。

如果这些都不是问题,那么我会随意使用最简单或最熟悉的方法。如果它是一种投入,请尝试CORS,因为它是更“现代”的解决方案,JSONP更像是一种黑客攻击,将数据转化为脚本以绕过跨域限制。然而,CORS通常需要更多的服务器端配置。

如果使用的是jQuery,我不确定在哪里提出CORS“ 对客户更友好更容易实现 ” 的想法。请参阅https://gist.github.com/3131951。jQuery对JsonP的细节进行了抽象,而CORS实际上可能在你的服务器端实现有点棘手,这取决于你使用的是什么技术。

我最近开发了一个web应用程序,使用jquery和backbone.js,它从我们控制的各种跨域Web服务中读取,最终使用Json-P而不是CORS,因为我们需要支持IE7,而且它更简单一些服务器端(我们运行的是Django w / DjangoRestFramework),和客户端的jquery几乎一样。

用户回答回答于

你很有魅力。如果不需要支持传统浏览器(6年前发布的浏览器),我一定会使用CORS。

CORS更容易实现,因为如果你的API不支持JSONP或CORS,只需添加一些静态头文件比修改响应体更容易。

使用CORS缓存请求也更容易。即使使用memcached内容,每个JSONP请求也必须是动态的。

JSONP仍然是一个脚本标记,所以不管它会引起某种程度的同步行为。CORS不会。

JSONP只能是GET。和CORS一样,你可以使用任何方法。

扫码关注云+社区