那么，JSONP还是CORS？
我的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本质上是只读的。
如果这两者都不是问题，那么我就随便select最简单或最熟悉的方法。 如果它是一个投入，尝试CORS，因为它是更“现代”的解决scheme，JSONP更多的是黑客，将数据转换成脚本来绕过跨域限制。 但是，CORS通常需要更多的服务器端configuration。
如果您使用的是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，那么只需要添加一些静态头就比修改响应体更简单。
使用CORScaching请求也更容易。 即使使用memcached内容，每个JSONP请求也必须是dynamic的。
JSONP仍然是一个脚本标记，所以不pipe它会引起什么级别的同步行为。 CORS不会。
JSONP只能是GET。 和CORS一样，你可以使用任何方法。
最后但并非最不重要的是，如果您使用的是jQuery v1.x ，那么在一些常见情况下（例如networking错误），仍然不会为JSONP请求调用error和complete （或更好的fail和always ）的处理程序。 当然有解决方法（超时设置，jQuery-JSONP插件），但是我发现CORS不那么恼人，特别是当跨域请求只来自移动设备（即混合应用程序），所以你不需要支持不幸的浏览器。
根据Spring Documentation的说法，JSONP是一种黑客行为，而非跨源资源共享的合适解决scheme。 因此，如果安全不是您的担心，那么只需在您的服务器上检查您的域名来源并添加Access-Control-Allow-Origin Response标题。
我们的Web API在Windows身份validation的Safari（iOS 9.1）上不起作用。 它正在与Safari + iOS 8.4一起工作。 当我们更改为JSONP Safari时，又开始工作了。 查看这个链接了解更多信息。
