RxLEO

Magora Systems的“Leopold API”实现

项目的首要目标

1. 丢弃ObjectMapper解码功能，因为这些功能自从Swiftlang第四大版本的上升以来已经过时了
2. 丢弃Alamofire，因为丢弃事物很有趣，但使用原始Alamofire则不有趣
3. 解决API中的主要不确定性和大量的// TODO:

注意

项目维护了一个示例使用源文件，您可以在./RxLEOSampleUsage中找到，它几乎涵盖了95%的使用情况。

项目状态

标签0.1引入了原始LEONetworkingLayer项目实现的基本服务器响应模型Swift.Codable端口。这几乎意味着对API严格定义的서버互相操作的规范化。

标签0.2引入了RxNick的实施路由能力和一个提供路由对象和RxNick响应原语之间交换的接口。路由法在很大程度上类似于原始实现中的样子。

Tag 0.3 对原始实现的路由部分进行了大幅重写，依赖于一个更成熟的 RxNick 版本。其中最显著的变更之一是，路由对象现在可以提供一个状态码的范围以供验证，预期的响应对象声明不再合并到路由的声明中，路由定义以及基础 URL 定义都变得异常简洁。然而，在这个版本中，除非你想让所有返回同一类型的对象，否则不支持使用枚举作为路由。

Tag 0.4 引入了对请求头覆盖和自定义状态码检查策略的支持。它也更新了 RxNick。

LEONetworkingLayer 的变更和迁移

服务器响应模型层变更

• LEOValueResponse 在这个实现中不存在，因为它在以前已被弃用。
  快速修复：LEOValueResponse ~> LEOObjectResponse
• LEOListResponse 的 data 字段现在不是指向从响应中解析出的项的数组，而是指向 LEOListModel 实例。这是由于重用了 LEOObjectResponse 的解析实现。
  快速修复：data ~> data.items

路由层变更

注意：RxNick 插入了一个理念，一个需要体（body）的路由和多一个带 URL 查询参数的路由应该有严格的多样性。这是由 HTTP 定义的，而不是我，它是正统的。

• 在 LEONetworkingLayer 中，您会为每个路由对象添加一个扩展，该扩展定义了一个具有 URL 类型获取器的属性，该获取器被用来解析终端的路径。
  这里有一个 LEORouter 类型，它由一个将用于解析路径的 URL 构建。
• 在 LEONetworkingLayer 中，一个常用的模式是使用枚举来表示 API 中不同的业务逻辑相关的部分。一个人会实现一个带有枚举的 LEORoute 协议，然后在路由的相应部分中切换每个获取器的案例。这非常臃肿，导致了不必要的 SLOC 增加并被一个资深 iOS 开发者标注为 这垃圾玩意儿是垃圾 需要简化。
  在这里，使用名为 bodyless 和 bodyful 的 LEORouter 对象的方法，这些方法接受路由行为配置的整体方案。这通常包括一个路径、HTTP 方法、一个消息体对象、用于解析响应的 Swift.Decodable、自定义头信息和自定义状态码验证策略。为了统一和可视化，可以将这些定义为一个空结构的静态成员。
• 在 LEONetworkingLayer 中，您可以通过程序员一直以来的额外操作来确定响应被解析到了哪个对象。
  在此处，返回对象的类型被设置为 LEORouter 的 bodyless 和 bodyful 产生的路由对象的组成部分，响应数据将为您解析并在 RxNick.Response.target 可用。

网络层变更

几乎所有的东西都是新的。现在有 RxLEOAPIProvider 协议及其基于 RxNick 的默认实现 RxLEODefaultAPIProvider。这种分离允许 API 模拟，这对客户端的可测试性很有好处。所以常见的使用策略，简要来说是这样的

1. 在客户端架构的某个地方管理一个 RxLEOAPIProvider 的实例
2. 管理一个 LEORouter，该路由负责将所有路由协议创建为一个基本 URL
3. 使用 LEORouter 的方法创建一个 LEOBodyfulRoute 或 LEOBodylessRoute
4. 将此类对象推送到 RxLEOAPIProvider.request 的一个方法中，这将产生一个 RxSwift.Single<RxNick.Response>
5. 您实际上想要检索的实际模型已经解析并出现在 Response 的 target 属性中。

为什么我应该在我项目中使用 Magora Systems 的 "Leopold API"?

正是因为这个原因，我们在这个世界上使用任何抽象。正是因为这个原因，操作系统被发明出来以摆脱裸机硬件的需要，图形用户界面被发明出来以摆脱终端的需要，等等。
它让你少想一些。由于 API 至上而下半是通用的，并能涵盖许多常见的 REST API 用例（更不用说分页、等等了），因此您与他人协作的需要也更少。这对于 Web 开发来说是非常好的。