相关疑难解决方法(0)

我正在重新思考我正在开发的大型应用程序的请求架构的方法.我目前正在使用ASIHTTPRequest实际发出请求,但由于在不同的视图控制器中采取了许多不同的操作,我需要许多不同类型的请求,因此我正在尝试找出组织这些请求的最佳系统.

我正在构建由应用代表保留的单身"请求者",并坐在那里听取需要发出请求信号的NSNotifications; 他们发出请求,听取响应,并发送带有响应数据的新NSNotification.这解决了我的大多数问题,但没有优雅地处理失败的请求或同时请求同一个单一请求者.

任何人都有成功设计一个清晰的OO架构,在iOS应用程序中制作许多不同类型的请求？

我正在开发iOS应用程序已有很长一段时间了.但最后我对网络层的架构设计从不满意.特别是当它连接API时.

这里可能有重复,但我认为我的问题更具体,你会看到.

构建iOS网络应用程序的最佳架构方法(REST客户端)

我不是在寻找像"使用AFNetworking/Alamofire"这样的答案.无论使用哪个第三方框架,此问题都是如此.

我的意思是,我们经常有这样的情景:

"开发一个使用API​​ Y的应用X"

这主要包括相同的步骤 - 每次.

1. 实施登录/注册
2. 您获得了身份验证令牌,必须将其保存在钥匙串中并将其附加到每个API调用中
3. 您必须重新验证并重新发送401失败的API请求
4. 您有错误代码要处理(如何集中处理它们？)
5. 您实现了不同的API调用.

3)的一个问题

在Obj-C中,我用NSProxy它在发送之前拦截每个API调用,如果令牌过期则重新验证用户,并触发实际请求.在Swift中NSOperationQueue,如果我们得到一个401并且在成功刷新后将实际请求排队,我们就有一些我们排队的auth调用.但这限制了我们使用Singleton(我不太喜欢),我们还必须将并发请求限制为1.我更喜欢第二种方法 - 但是有更好的解决方案吗？

关于4)

你如何处理http状态代码？每个错误都使用许多不同的类吗？您是否将一般错误处理集中在一个类中？您是在同一级别处理它们还是更早地捕获服务器错误？(也许在你的任何第三方lib的API Wrapper中)

你是如何开发人员试图解决这个问题的？你有没有找到"最佳匹配"的设计？你如何测试你的API？特别是你如何在Swift中做到这一点(没有真正的嘲弄可能性？).

当然:每个用例,每个应用程序,每个场景都是不同的 - 没有"一个解决方案适合所有人".但我认为这些一般问题经常出现,所以我很想说"是的,对于这些情况 - 可能有一个或多个解决方案 - 你可以每次都重复使用".

期待有趣的答案!

干杯
奥兰多