一个比较难受的需求

[QIYA0130]

有这样一个需求，App 大量的请求需要依赖一个 ticket。
对这个 ticket 的设计是 30 分钟时效，要客户端自己做时间戳判断，过期就要先请求 ticket，再发本来的请求。
这样我无论如何都想不到比较优雅的方法在底层处理，不知大神有没有想法。

[zzscc]

有这样一个需求，App 大量的请求需要依赖一个 ticket。 对这个 ticket 的设计是 30 分钟时效，要客户端自己做时间戳判断，过期就要先请求 ticket，再发本来的请求。 这样我无论如何都想不到比较优雅的方法在底层处理，不知大神有没有想法。

你怎么处理的？

[casatwy]

因为apimanager的参数是通过pramesource获取的，所以只要paramsource实例还在，这个APImanager的实例就可以保存下来，然后先调用ticket的api，再调用刚刚保存的apimanager的loaddata方法就好了。 发自我的iPhone 在 2021年11月15日，12:41，zzscc ***@***.***> 写道：  有这样一个需求，App 大量的请求需要依赖一个 ticket。 对这个 ticket 的设计是 30 分钟时效，要客户端自己做时间戳判断，过期就要先请求 ticket，再发本来的请求。 这样我无论如何都想不到比较优雅的方法在底层处理，不知大神有没有想法。 你怎么处理的？ — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#28 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAHVRVOZATSGHDWYRWONKHTUMCFOVANCNFSM4IPBDJUQ>.

[zzscc]

因为apimanager的参数是通过pramesource获取的，所以只要paramsource实例还在，这个APImanager的实例就可以保存下来，然后先调用ticket的api，再调用刚刚保存的apimanager的loaddata方法就好了。 发自我的iPhone 在 2021年11月15日，12:41，zzscc @.***> 写道：  有这样一个需求，App 大量的请求需要依赖一个 ticket。 对这个 ticket 的设计是 30 分钟时效，要客户端自己做时间戳判断，过期就要先请求 ticket，再发本来的请求。 这样我无论如何都想不到比较优雅的方法在底层处理，不知大神有没有想法。 你怎么处理的？ — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#28 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAHVRVOZATSGHDWYRWONKHTUMCFOVANCNFSM4IPBDJUQ.

最近看大佬的文章，倍感启发。这个框架是我看到最优雅的网络封装了，对于这个框架还没完全掌握，有两个疑问想请教下大佬：

1. 对于批量请求和链式请求，框架是怎么处理的呢？
2. 离散型的话，每个请求都要创建个Manager. 如果一个业务同时需要请求6个接口，要创建6个manager 不是很繁琐吗？

[casatwy]

这个框架请求的本质就是调用APIManager对象的loadData方法。
所以批量请求其本质也只是获取APIManager对象数组然后调用这个数组里对象的loadData方法。
链式请求也是在上一个APIManager对象的回调里面调用下一个APIManager对象的loadData方法而已。

对于这两种请求场景来说，调度器不需要关心到底是什么APIManager，他只要拿到实例调用loadData方法就好了，调度器也不需要关心参数从哪里来，因为都是走的paramSource。

对于链式请求来说，发起下一次请求的时机可以是在业务里，也就是业务实现calback delegate的地方。也可以是在自己的APIManager里，因为APIManager提供了interceptor，interceptor提供了一个APIManager的完整生命周期。所以如果是业务场景的链式调度需求，那就写在业务代码中。如果是固定的链式调用需求，那就写在APIManager自己的interceptor里。

前面提到了调度器，由于调度器的本质就是调用一个对象的固定方法，所以实现调度器是一个很简单的事情。但是不同的业务需求又影响调度器的实现，所以这个框架里并不提供调度器的实现，你可以自行实现，不难的。

对于第二个问题，一个业务要调用6个接口创建6个APIManager，正是因为这么做了，所以你才能用上面的方式解决问题。如果是集约型调度，所有API都走一个地方，你就很难针对每个不同的APIManager做生命周期的不同处理了。