客户端一个处理多个请求的弊端及解决方案

客户端一个处理多个请求的弊端及解决方案

解决方案有以下几种： 1.服务器给你把一个处理的多个请求合并成一个请求（业务无关），你向服务器发送一个请求，服务器向不同业务服务器发送请求，等所有的业务请求都回来后，服务器合并成一个请求给你。通常原来的分请求在其他地方也有使用，所以通常也保留各个分请求，就是服务给你提供一个合并后的接口。必定这样的处理是少数的。 2.若服务器过于复杂，不只对你一个app服务，还为多个网页服务，多个app服务，服务器开发人员不想给你合并请求。可以通过服务器人员开发出来一个聚合层网关，多所有的请求进行编号，每次发送合并请求是发送请求编号和对应参数，请求编号可以为多个。服务器通过请求编号，解析对应的参数，向业务服务器发送请求。 3.服务器不配合，不给你合并请求接口，也没有聚合层，那么app只能通过app自己处理了。可以通过RACSignal的zipWith压缩信号来达到多个请求都成功合并成一个消息后出发组合消息。当然这种方法，前四个缺点都存在。（当然你没有引入ReactiveCocoa这个第三方库也没有办法使用）。 发送信号 交互顺序，元组内元素的顺序不会变，跟发送的顺序无关，而是跟压缩的顺序有关[signalA zipWith:signalB]—先是A后是B。 4.定义几个变量，每一个消息成功把它返回的数据都先存起来，设置成功标志，判断是不是所有的消息都设置了成功标志。这种方法，所有缺点都存在。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。