正文
到目前为止，我们已经看了一个简单的Request/Response的结构体和实现。接下来，我们来讨论一下发送请求和接收响应。
如果我们回想一下第一节，我们会用HTTP回调给他，我们发送了一个请求，并且最终得到了一个响应（忽略Error）没有任何“任务”或者代理亦或其他什么东西。我们发送（或加载）一个请求，最终都会得到一个响应。
如果我们用一个方法来描述那个功能，那么这个方法如下所示
|
1
|
func load(request: HTTPRequest, completion: @escaping (HTTPResponse) -> Void) |
我们发送了一个请求，在未来的某个节点，闭包将会被执行，表里涵盖的是我们要的响应。当然，单个方法并不是我们想要的；换句话说，我们想要表述的是一个接口。所以，我们会把他封装进一个protocol中:
|
1
2
3
|
public protocol HTTPLoading { func load(request: HTTPRequest, completion: @escaping (HTTPResponse) -> Void)} |
当然，我们可能会得到一个error响应。所以，我们要用自己的“results”重命名(typealiase)来替换HTTPResponse:
|
1
|
func load(request: HTTPRequest, completion: @escaping (HTTPResult) -> Void) |
让我们停下来欣赏一下。 这个方法就是我们定义网络框架的核心功能所需要的全部。 就是这样：一个方法。 棒极了。
遵循HTTPLoading协议
URLSession就像“路上的橡胶”,这是在我们的请求通过空中（或有线）发送到我们指定的服务器之前需要清除的最后一个障碍。 因此，我们在 URLSession 上实现 HTTPLoading 是为了将 HTTPRequest 转换为会话需要的 URLRequest，这是有道理的：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
extension URLSession: HTTPLoading { public func load(request: HTTPRequest, completion: @escaping (HTTPResult) -> Void) guard let url = request.url else { // we couldn't construct a proper URL out of the request's URLComponents completion(.failure(...)) return } // construct the URLRequest var urlRequest = URLRequest(url: url) urlRequest.httpMethod = request.method.rawValue // copy over any custom HTTP headers for (header, value) in request.headers { urlRequest.addValue(value, forHTTPHeaderField: header) } if request.body.isEmpty == false { // if our body defines additional headers, add them for (header, value) in request.body.additionalHeaders { urlRequest.addValue(value, forHTTPHeaderField: header) } // attempt to retrieve the body data do { urlRequest.httpBody = try request.body.encode() } catch { // something went wrong creating the body; stop and report back completion(.failure(...)) return } } let dataTask = session.dataTask(with: urlRequest) { (data, response, error) in // construct a Result<HTTPResponse, HTTPError> out of the triplet of data, url response, and url error let result = HTTPResult(request: request, responseData: data, response: response, error: error) completion(result) } // off we go! dataTask.resume() }} |
这应该很容易理解。 我们正在执行从 HTTPRequest 值中提取信息并将其应用于 URLRequest 的步骤。 如果在任何时候出现问题，那么我们将报告错误。 （您需要自己填写 ... 部分以构造适当的 HTTPError 值）
假设构建一切顺利，我们最终会得到一个 URLRequest，我们可以将其转换为 URLSessionDataTask 并执行它。 当它完成时，我们将获取响应值，将它们转换为 HTTPResult，并通过完成块报告回来。
创建Result
在传输过程中的任何时候，我们的请求都可能失败。 如果我们处于飞行模式或其他“未连接”状态，则请求可能永远不会发送。 如果我们正在发送请求（在我们得到响应之前），网络连接可能会断开。 或者它可能会在我们发送后但在我们收到回复之前掉线。 或者它可能会在我们开始收到响应之后但在完全接收到响应之前下降。
这就是我们在定义请求和响应类型时创建 HTTPError 结构的原因，这意味着我们需要更加努力地构建我们的结果，而不是简单地检查“我是否得到了一些数据”。
在高层次上，初始化 HTTPResult 的逻辑大致如下所示：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
var httpResponse: HTTPResponse?if let r = response as? HTTPURLResponse { httpResponse = HTTPResponse(request: request, response: r, body: responseData ?? Data())}if let e = error as? URLError { let code: HTTPError.Code switch e.code { case .badURL: code = .invalidRequest case .unsupportedURL: code = ... case .cannotFindHost: code = ... ... default: code = .unknown } self = .failure(HTTPError(code: code, request: request, response: httpResponse, underlyingError: e))} else if let someError = error { // an error, but not a URL error self = .failure(HTTPError(code: .unknown, request: request, response: httpResponse, underlyingError: someError))} else if let r = httpResponse { // not an error, and an HTTPURLResponse self = .success(r)} else { // not an error, but also not an HTTPURLResponse self = .failure(HTTPError(code: .invalidResponse, request: request, response: nil, underlyingError: error))} |
用法
HTTPLoading 使用方法:
|
1
2
3
4
5
6
7
8
9
10
11
12
|
public class StarWarsAPI { private let loader: HTTPLoading = URLSession.shared public func requestPeople(completion: @escaping (...) -> Void) { var r = HTTPRequest() r.host = "swapi.dev" r.path = "/api/people" loader.load(request: r) { result in // TODO: interpret the result completion(...) } }} |
我想在这里指出，我们在任何时候都不会解释Response的状态代码。 获得 500 Internal Server Error 或 404 Not Found 响应是成功的响应。 在这一层，“成功”意味着“我们得到了回应”，而不是“回应表明某种语义错误”。 解释状态代码是特定于应用程序的逻辑。 在未来的帖子中，我们将允许基于状态代码的可定制的、特定于应用程序的行为（例如跟随重定向或重试请求）。
我们定义的这个单一方法看似简单，但也不完整。 我们还没有指出任何主动取消请求的方法，我们需要调整我们的 HTTPLoading 协议以添加更多功能。 我们还将把它从协议转换为类，原因我将在以后的帖子中解释。
尽管存在这些小漏洞，该协议在其简单性方面仍然很漂亮，它展示了一个好的问题概念化如何能够产生强大而美丽的东西。
简单是最终的复杂。
在下一篇文章中，我们将研究使用 HTTPLoading 协议来简化单元测试。
以上就是Swift HTTP加载请求Loading Requests教程的详细内容，更多关于Swift HTTP加载请求的资料请关注服务器之家其它相关文章！
原文链接：https://juejin.cn/post/7196888211758759996
