带有Rage的iOS中的实用网络
这篇文章是关于Rage的，Rage是我们的库，用于抽象iOS中的API实现。
如今，很少有移动应用程序没有API。 因此，我们必须每次为每个新项目创建网络层。
从移动开发的角度来看，我们看到每个后端的实现方式有何不同。 它在很大程度上取决于所选的服务器技术，例如严格且可预测的Java和.net，灵活且不同的node.js，ruby和python。
同时，在处理移动应用程序时，我们始终具有相同的技术堆栈，并且我们希望拥有清晰可预测的代码，每个项目看起来都相似。
世界状况
当您从Android世界过渡到iOS开发领域时，您将不可避免地对这里非常流行的模式感到惊讶。
出于联网目的，Apple的URLSession相当不错，但是许多项目仍使用Alamofire （它是AFNetworking的后继产品） 。 有Moya ，它比Alamofire更高 。 Moya很不错，我们在某些项目中使用了它。 它有充分的文档证明和测试，但是它的枚举滥用语法是我们无法忍受的。 在相同的枚举中，API描述立即变成大量的开关盒。 单个请求的每个参数都在其自己的位置描述，当您尝试了解单个请求的所有内容时，这确实令人困惑。 我们接受Moya的意识形态认可，但这会影响我们的生产力。 有时候，看起来像莫亚（Moya）自己陷入了困境。
Android世界的主要流行词是OkHttp ， Retrofit和Moshi 。 没有人质疑他们为什么这么好。 我们也自然希望在iOS中也有这样的事情。 Swift没有我们在Java / Kotlin中常用的注释处理，因此在此处进行直接类似并不容易。 据说， Swift 4解决了JSON问题。 OkHttp为网络请求规范提出了一种不错的构建器样式语法。 Retrofit提出了一种描述请求列表的方法，如何对数据进行序列化/反序列化以及应使用哪个http客户端进行请求。
愤怒
愤怒做了类似的事情。 这是我们的库，使API规范更具可读性和更清晰。 我们努力减少错误，并力争拥有高定制能力。 这就是我们创建Rage的原因 。
我们之所以给该库起这个名字，是因为在使用该库之前在iOS应用中实现API时必须处理的所有事情。
基本上，我们可以将网络层表示为请求描述列表以及有关一般如何发出请求（即客户端）的信息。
客户发出请求。 它知道有关所有请求的常规信息。
每个请求都有其自己的特定参数。
至此，我们为客户端提供了以下参数：
- 基本网址
- 基本ContentType
- URLSessionConfiguration
- 一些插件，例如记录器
- 所有请求的标题
- 请求授权流程说明
这是我们对每个特定请求的要求：
- 网址
- 内容类型
- HTTP方法
- 相对路径
- 标头
- 查询参数（键值，无值，数组）
- 路径参数
- 如果此请求需要授权
对于特殊情况，我们经常使用辅助方法：
- 带主体的请求（从
Data，String，任何Codable对象创建主体） - 分段请求（创建分段请求从未如此简单）
- FormUrlEncoded请求（创建包含键/值参数列表的主体）
序列化和反序列化也可以集成到请求过程中。 我们的目标是使用严格类型的对象，而不是我们在许多项目中看到的字典地狱。 老实说，我们讨厌这些[String: Any?]东西。 现在在Swift 4中 ，我们有了Codable因此我们可以在请求主体中传递Codable对象，并将其序列化为json。 我们可以指定请求Codable返回类型，并从json获取反序列化的对象。
与Moya相比， Rage中的流程非常简单。 每个请求都包含在描述所有参数的自己的函数中。
我们的主要功能之一当然是RxSwift支持，这使Rage的使用更具利润率。
这就是简单情况下的样子
如您所见，这在外部代码中使用非常简单。 它只是一个函数getOrgInfo("gspd-mobi") ，它在您的业务逻辑中像在代码中的任何其他函数一样被调用。
一个复杂的案例看起来并没有太大不同。
您是否要从Codable对象向一个请求添加查询参数，路径参数，json主体？ 没问题。 在此请求链中仅再进行了三个函数调用。
您是否要仅使用Rage创建请求以供以后使用？ 没问题， .rawRequest()函数适合您。
愤怒并不强迫开发人员使用任何架构模式。 基本上，这只是描述请求的便捷方法。
该库建立在Apple的URLSession之上 ，并使用Result微库来封装Content / Error逻辑以用于没有RxSwift的用例。
一探究竟
每个人都可以查看Rage的全部含义。 通过CocoaPods安装它或使用Github中的代码。
但是请不要在1.0.0之前的版本中使用它。 它还不够稳定，其API可能会在版本之间变化，而没有向后兼容性。 我们在所有项目中都使用了它，我们从错误中学习，逐渐了解了我们需要添加哪些新功能，某些旧解决方案存在哪些缺陷以及必须如何根据我们的需求更新该库。 它已经有2年历史了，我们现在真的要发布稳定版本了。 自从发布Rage的初始版本以来，我们已经在所有应用程序中成功使用了Rage，并且很高兴在iOS中实现API。
也有可用的文档，其中包含有关库功能的所有基本信息。 此外，还有一个“示例”项目，可让您查看实际运行的Rage 。