2017 年，你还在用 JSONP 吗？

[eric6356]

太长不看

JSONP 就是个 dirty hack ，吃枣药丸，能不碰就不碰。不服来辩！

细节

即将接手一个前端项目。
这项目之前是用 Rails + Angular1 做的，现在我们打算把 Rails 干掉，所有数据都让前端直接从 api.example.com 取。
后端 api.example.com 一定是我们自己 serve ，但前端的话：

1. 可能部署 NGINX 到各个客户服的务器上
2. 也可能是我们自己的 admin.example.com
3. 当然更有可能同时会有好几套，这还不确定

之前的思路是，前端判断一下其所处的环境是否支持 CORS ，不行的话用 JSONP 当做 fallback 。至于 GET 以外的请求，这边用 JSONP 模拟了一套实现，看起来相当完善，前后端都有支持。并且我们的请求都很小，似乎不用考虑 413 的问题。

而现在我个人的想法是，无论部署在哪，都让跑这个项目的那个 NGINX 做一次 proxy_pass ，反代到 api.example.com （对应 1 ），或是反代到我们私有网络跑 api 的那台机器上（对应 2 ）。这样的优点至少有：

1. 跨域这件事情根本不存在了，也不用去考虑 CORS 的各种坑
2. 客户方面，只需要跑 NGINX 的那台机器连得到 api.example.com 就行，跑浏览器的机器可以是纯内网环境

缺点：

1. 多了一次代理转发，做反代的机器机器会有额外性能开销（如果和 api 不是同一个 NGINX 的话）
2. 本来前端所有的文件可以都交给 CDN ，现在则必须要一台服务器了

总之在我印象中，JSONP 这玩意就是落后于时代（亦或是超前于时代）的一个 hack 。以前、现在、未来都未曾、没有、不会出现在 W3C 或是 RFC 标准中，应该被抵制才对。

我目前还没有说服团队成员放弃 JSONP ，尤其是用 JSONP 模拟实现了一整套非 GET 请求的前辈。
请各位 dalao 赐教。

[k9982874]

我支持 pass_proxy 的解决方案，我司正在开展的项目和你的项目差不多情况。
sever 只提供 API 的情境下不需要考虑用户 cookie 。
另外当用户到达反代服务器承受不了的情况下，业务服务器早挂了。
用户到达那个数量级应该有大把的资金去增加服务器资源。

[sagaxu]

@eric6356 这种防火墙后面，一堆 APP 都会受影响无法工作，所以不用考虑这种情况。而且 ssl 加密后，防火墙根本不知道传输的内容，一个四核 CPU ，可以轻松承受几千万 pv 的 https 转发工作。

更多需要考虑的，其实是 IE8 和 IE9 的兼容性问题。在初期，设计上不能轻易放弃 fallback 的能力。

[sagaxu]

@k9982874 nginx 代理成瓶颈的时候，融资都融几个亿了

[AntiGameZ]

@eric6356 虽然有点俗套，但是还是想问一下图是用什么方法画的，看上去很棒。

[eric6356]

@AntiGameZ https://monodraw.helftone.com

[changwei]

@otakustay cros 同样也可以 get ， jsonp 的安全问题在于提供 jsonp 数据源的服务器如果被黑或者数据源提供商自己想做一些不可描述的事情，将会影响到使用它的网站，尤其是 jsonp 的提供商如果被黑产控制，增加菠菜暗链可能还会影响 seo 。

[otakustay]

@changwei 是我没说清楚， jsonp 最大的问题是与普通的 HTTP 请求使用同样的 GET ，无法使用 Access-Control-*这样协议级别的东西进行访问控制，导致对任何访问者是平等对待，鉴权和访问控制就必须自行实现，相对于协议来说要弱一些

[undeflife]

@eric6356 我的观点其实和你的做法是一致的,既然可以通过 nginx 反代解决,就没有必要在代码层面复杂化，特别是因一个还不明确的未来可能有的业务点,将整个代码的设计基于 jsonp 这样一个 hack 手段上,不太适合.
至于反代的性能损耗,没有具体请求数据的情况下,属于过早的讨论优化的问题.

另外根据你的帖子,你们认为应用有出售的潜在可能性,那么你们会上 https 吗？会有 api 请求频次的限制吗？相比 jsonp 而言,这些更应该考虑吧？