我正在构建一个基础设施来支持我们打算扩展到数十万用户的游戏平台。由于这是在娱乐/游戏行业，我们预计每个用户会话都会产生沉重的负担，因此，性能是最重要的。
我们正在尝试尽可能多地并行化架构，这意味着 API、数据库和应用程序运行在可以水平扩展的不同服务器上。其中一个应用程序是 Web 应用程序，由于涉及旧版浏览器上的同源策略的特定场景，我们遇到了最大的麻烦。
在 Web 浏览器中运行的这个应用程序需要快速访问只能通过集中式 API 获得的模型。虽然这对我们的专用移动客户端来说非常有用，但不幸的是，浏览器需要完全支持 CORS 才能直接与我们的 API 交互。这是有问题的，因为并非所有浏览器都支持某些 HTTP 动词（放置/删除）。我们唯一已知的解决方法是，重写 API 以创建更多抽象（我们认为这不是最佳实践，并且会增加开发时间和潜在的性能）并使用 JSONP 仅使用 POST 或创建代理（这将增加额外的两条腿到旅行并加倍延迟性能）。
底线是，我们已经将这个问题归结为......这是仅有的两个选项，还是我们没有考虑其他一些选项，如果是，这些解决方案中的哪一个更适合游戏平台。
另一个要考虑的选择是JSONP。通过包装 JSON 响应以使其能够作为脚本标签加载，您可以避免同源策略的问题。
如果不详细了解应用程序，我无法谈论您的特定应用程序的性能问题。我认为您会在使用 JSONP 的服务器上看到类似的性能，因为您与其他方法的主要区别在于您连接了一个额外的字符串。
SOP应该不是问题。将 JSONP 用于跨域请求。将答案包装在回调方法中对于您的服务器端部分来说不应该是问题，并且对于应用程序的其余部分应该是透明的。不会破坏 REST 风格。在客户端库上，JSONP 的使用对于应用程序的其余部分也应该是透明的。
那么，PUT 和 DELETE 是什么？只需执行 POST 并使用预期的方法设置 X-HTTP-Method-Override 标头。服务器端的 Web 服务处理程序应识别标头并使用标头中的方法暗示请求。对应用程序的其余部分都是透明的。
虽然 JSONP 确实具有“通用”支持 - 它仍然有点 hacky 并且有一些负面影响：主要是您无法捕获错误。
JSONP 在任何地方都有效的原因是脚本标签发出的请求属于 CORS 规范所定义的“简单请求”的范围。
我的观点？除了使用 JSONP，您还可以修改您的 API（或至少是其中最常访问的部分）以适应简单请求的范围。然后，您将获得处理错误的全部能力，而不会受到预检请求的任何性能影响。
对于必须使用预检请求的地方，您可以缓存预检响应。
我在两个 Strategies for Crossing Origins with Mind of Performance 中对这项技术进行了完整的描述