我正在考虑使用 Web API 建立一个项目。基本上首先构建 API 并使用此 API 对网站进行编程。
虽然这听起来很有希望,但我想知道:如果我以一种很好的方式分离逻辑,我最终可能会通过多个 API 调用检索网页上的数据,这反过来又是与服务器的多个连接以及所有开销等。
例如,如果我在一个页面上使用 8 个不同的 API 调用,我无法想象它不会对网页的性能产生影响。
那么,我是不是误会了什么?或者这种开销可以忽略不计 - 或者多次调用的需要是否表明设计是错误的?
提前致谢。
我正在考虑使用 Web API 建立一个项目。基本上首先构建 API 并使用此 API 对网站进行编程。
虽然这听起来很有希望,但我想知道:如果我以一种很好的方式分离逻辑,我最终可能会通过多个 API 调用检索网页上的数据,这反过来又是与服务器的多个连接以及所有开销等。
例如,如果我在一个页面上使用 8 个不同的 API 调用,我无法想象它不会对网页的性能产生影响。
那么,我是不是误会了什么?或者这种开销可以忽略不计 - 或者多次调用的需要是否表明设计是错误的?
提前致谢。
好吧,我们做到了。Web API 服务器提供对所有数据的 REST 访问。独立的UI 客户端将其用作底层持久性的唯一访问点。
第一个请求需要一些时间。它明显更长。它必须初始化所有 UI 客户端的东西,并从服务器获取最少需要的数据。(菜单、用户、访问权限、元数据...列表视图数据)
重点,真正的优势,隐藏在第二个,第三个……请求中。UI 客户端上已经有很多东西了。甚至,如果再次请求,可以引入缓存(服务器、客户端,两者)。
所以,这将意味着更多的请求(至少在 UI 客户端启动期间)......但这并不意味着......更慢的应用程序。
维护的好处 在Separation of Concern中是隐藏的(也许不是隐藏的,应该是显而易见的)。在服务器上,我们不再解决问题,在哪里放置用户数据处理,基本控制器或子控制器......应该在母版页,布局控制器......
解决了。我们正在关注通过 REST 发布的单一、特定的内容。一种方法,一种业务操作。如果我们想保持该应用程序的活力并成为修理工和扩展程序,这就是我们的梦想。
大多数现代浏览器支持到同一站点的 6-8 个并行连接。所以你必须要小心。除非您要连接到那么多单独的系统,否则我会尝试减少连接数。或者确保调用被不同的事件异步调用,以减少并行连接的机会。
进行一系列 HTTP 调用以获取页面数据将产生开销。只有测试会告诉您这可能会如何影响您的场景。
仅仅因为你可以使用 Web API 并没有什么意义。您应该有正当理由构建 RESTful API。即使这样,如果它主要是供您自己使用的,请将其设计为在一次调用中为每个页面提供一个 ViewModel。
一方面是您可以非常非常快速地将页面显示给最终用户。加载页面后,使用 Jquery 异步调用和任何 Javscript 模板工具(如 angularjs 或 mustacheJs)同时调用 Web api 以构建客户端页面视图。
我在多个项目中使用过这种方法,用户体验非常好。