我的浏览器中有多个AJAX请求。 我的UI由多个视图组成,AJAX请求正在尝试同时填充这些视图。在某些情况下,我需要从客户端发送10个以上的同时请求,并在服务器上同时处理。
但由于browser limitations on max concurrent requests to a single domain和HTTP的“A server MUST send its responses to requests in the same order that the requests were received”约束,我在请求处理中并没有像我希望的那样获得尽可能多的并发性。
从我的应用程序的角度来看,我不需要响应按照我发送请求的顺序。如果view8在view1之前填充,我就没问题了。例如。
使用Servlet 3.0构造的异步处理似乎只能解决问题的一个方面(服务器端),因此无法充分利用它来最大化应用程序并发性。
我的问题是: 我是否错过了一些正确的构造?(与“host your images from a different sub domain”之类的解决方法形成对比的“正确”)可以让我获得更多的并发性?
这似乎是许多Web UI需要的东西!如果没有,那么我正在以错误的方式设计我的UI。在任何一种情况下,我都很感激您的意见。
Edit1:就我而言,我不必支持大量的并发客户端。访问该应用程序的最大并发客户端数将是< 100.鉴于这一事实,当我在服务器端拥有大量处理能力时,基本上我正试图增强这些客户的体验。
Edit2:我们的应用程序/ API不适用于“公共”消费。例如:这就像我公司的网络邮件应用程序。它托管在互联网上,但并不适合每个人的消费。仅供相关少数人消费。 我提供该信息的原因是为了区分我的应用程序与SO / Twitter,这似乎区分了他们的(REST)API用户和他们的普通网站用户。在我们的例子中,我们认为我们不应该区分这种方式,并且希望为两者提供单组REST端点。
规范(RFC2616)限制背后的原因似乎是:“这些指南旨在改善HTTP响应并避免拥塞。”但是,Intranet Web应用程序有更多的奢侈品,不应该受到如此限制!?
答案 0 :(得分:1)
嗯,恕我直言,务实是更重要的。当然,服务公开RESTful API是有意义的,但并不总是需要将整个API暴露给浏览器。您的API可以与服务器端Web应用程序分开。您始终可以在服务器端进行多个API请求,整理结果并将其发送回客户端。对于例如看看SO主页。 StackOverflow API确实公开了RESTful API,但是在加载主页时,浏览器不会发送多个请求,只是为了填充标签,线程列表等。服务器正在公开REST API,因此UI会进行特定的GET 各种资源catogories(例如:博客,视频,新闻,文章)。 由于每个资源目录都有其独有的视图,所以它都适合 很好。整理获取博客和视频的请求是错误的 在一个请求中一起。不是吗?
感谢Sanjay提出的建议。但是我们想要一个单一的API 适用于REST客户端和浏览器客户端。有趣的是,根URI SO的REST API中没有提到“stackoverflow.com”,而是浏览器 客户使用它。我想如果他们暴露了根URI,他们的 反应将难以处理(因为它将是混合的 数据)。他们的REST API是粒度的(就像在我的应用程序中一样),但他们的 javascript代码使用其他一些门(API)来减少否。的 往返服务器!某种程度上感觉不对(我是新手 虽然在这个领域)。随意纠正我
所以不使用任何“其他门”。只是他们根本不发送10个并发请求来填充页面上的内容。他们在投票时提出XHR请求,将线程标记为收藏,评论等。对于加载页面本身,没有多个请求。如果您想直接从浏览器中访问RESTful API,则必须遵守这些限制。无论是那种还是走桌面方式,它允许你几乎无限制地连接到你的服务器,但我想你不想走那条路......