H Гибкий сетевой слой в iOS-приложении в черновиках

Практически любое мобильное приложение взаимодействует с серверами через их API. Перед разработчиком в таком случае стоит задача реализовать сетевой слой своего приложения. Провайдеры того или иного API разрабатывают его интерфейс, зачастую, одинаково, но бывает и так, что API имеет свою специфику. Например, API Вконтакте при какой-либо ошибке в обращении к их методам не отображает это в статус коде ответа, а отображает это в самом теле ответа как JSON по ключу «error»: то есть, во-первых, вы не поймете по статус коду прошел ли запрос удачно, а во-вторых, не узнаете, какая произошла ошибка пока не измените логику обработки ответа. Таким образом, перед разработчиком лежит задача реализации достаточно гибкого слоя, контроль над которым можно осуществлять на разных этапах работы с сервером.

Я хочу рассказать, как можно построить достаточно гибкий сетевой слой.

Вот как это будет выглядеть в итоге:

import UIKit

class ViewController: UIViewController {

    let service: WallPostable = BasicWallAPI()
    
    @IBOutlet weak var textField: UITextField!

    @IBAction func postAction() {
        service.postWall(with: textField.text!)
    }
}

Итак, как выглядит работа с API для конечного пользователя (я имею в виду программиста, который использует реализацию слоя):



Немного раскроем ящик API:



Как я вижу ящик Send:



Мы формируем запрос. Обычно запросы имеют некоторые одинаковые хэдеры и чтобы не прописывать их в каждом запросе, мы подготавливаем запросы в блоке «Request Preparation». Далее полноценно собранный запрос мы отправляем, используя удобный для нас фреймворк (В моем примере я использую нативный фреймворк от Apple). Отправить запрос всегда самое простое, все сложное начинается при получении ответа.

Как я вижу ящик Handle:



Пришедший ответ мы проверяем на успешность выполнения, далее в случае успешного ответа мы преобразуем его в модель понятную для приложения и отдаем. Если запрос выполнился не успешно, то мы отдаем его в блок обработки ошибки: он достает код ошибки, сообщение если оно имеется, реагирует на все это как мы ему говорим, формирует ошибку понятную для приложения и отдает.

Сетевой слой, который я реализую разделяет каждое действие и инкапсулирует его в соответствующем типе, который будет реализовывать эту свою единственную обязанность. Связаны между собой эти типы будут по протоколам.

Итак, что нам нужно:

• Запрос
  
  

  enum HTTPMethod: String {
      case GET
      case POST
      case PUT
      case DELETE
  }
  
  protocol HTTPRequestRepresentable {
      var path: String { get set }
      var httpMethod: HTTPMethod { get }
      var parameters: JSON? { get set }
      var headerFields: [String: String]? { get set }
      var bodyString: String? { get set }
  }
  
  extension HTTPRequestRepresentable {
      func urlRequest() -> URLRequest? {
          guard var urlComponents = URLComponents(string: self.path) else {
              return nil
          }
          
          if let parametersJSON = self.parameters {
              var queryItems = [URLQueryItem]()
              for (key, value) in parametersJSON {
                  queryItems.append(URLQueryItem(name: key, value: value as? String))
              }
              urlComponents.queryItems = queryItems
          }
          
          guard let url = urlComponents.url else {
              return nil
          }
          
          var urlRequest = URLRequest(url: url)
          urlRequest.httpMethod = self.httpMethod.rawValue
          urlRequest.allHTTPHeaderFields = headerFields
          if let body = bodyString {
              urlRequest.httpBody = body.data(using: .utf8)
          }
          
          return urlRequest
      }
  }
  

• Отправитель запроса, который будет описан позже
• Обработчик ответа
  
  

  
  enum Result<T> {
      case Value(T)
      case Error(ErrorRepresentable)
      case None
  }
  
  protocol ResponseHandler {
      associatedtype ResultValueType
      
      func handleResponse(_ response: ResponseRepresentable, completion: (Result<ResultValueType>) -> ())
  }
  

• Модель, в которую мы хотим преобразовать ответ
  Этот слой построен с учетом прекрасной возможности в Swift 4, которая предоставила нам такой протокол как Decodable, при реализации которого ваша модель будет самостоятельно (почти) создана из пришедшего ответа.
  

Отправитель запроса нуждается в:

• Подготовителе запроса
  
  

  <source lang="swift">
  protocol RequestPreparator {
      func prepareRequest(_ request: inout HTTPRequestRepresentable)
  }
  

Обработчик ответа в свою очередь нуждается в:

• Валидаторе ответа (проверяет ответ на успешность)
  

  protocol SuccessResponseChecker {
      func isSuccessResponse(_ response: ResponseRepresentable) -> Bool
  }
  

• Обработчике неудачного ответа
  
  

  protocol ErrorHandler {
      var errorCodeHandler: ErrorCodeHandler { get set }
      var errorCodeGetter: ErrorCodeGetter { get set }
      var errorMessageGetter: ErrorMessageGetter { get set }
      
      func handleErrorResponse(_ response: ResponseRepresentable, completion: (ErrorRepresentable) -> ())
  }
  

• Преобразователе ответа в модель
  
  

  protocol DecodingProcessor {
      associatedtype DecodingResult
      
      func decodeFrom(_ data: Data) throws -> DecodingResult
  }
  

А обработчик неудачного ответа нуждается в:

• Геттере ошибки
  
  

  protocol ErrorCodeGetter {
      func errorCodeFrom(_ response: ResponseRepresentable) -> Int
  }
  

• Геттере сообщения
  
  

  protocol ErrorMessageGetter {
      func messageFromErrorData(_ data: Data) -> String
  }
  

• Обработчике кода выявленной ошибки
  
  

  protocol ErrorCodeHandler {
      func handleError(with code: Int)
  }
  

Теперь об отправителе запроса. Им в нашем случае будет являться сервис, которому передается запрос, на нем лежит обязанность отправить его и затем передать ответ обработчику ответа.

protocol Service {
    associatedtype ResultTypeValue: Decodable
    
    typealias SuccessHandlerBlock = (ResultTypeValue) -> ()
    typealias FailureHandlerBlock = (ErrorRepresentable) -> ()
    
    var request: HTTPRequestRepresentable? { get set }
    var responseHandler: HTTPResponseHandler<ResultTypeValue>? { get set }
  
    func sendRequest() -> Self?
}

Себя мы будем возвращать для реализации Method Chaining'а.

Как видите я только описал протоколы, по которым вся эта система будет общаться с объектами внутри системы. Это дает нам возможность контролировать любой нужный нам этап, просто инжектировав свою реализацию протокола.

Нередко бывает так, что для более чем одного запроса при ошибке приходит один и тот же код, но означает он для них совершенно разное. Когда сервис — один большой объект, который все сам и обрабатывает, возникают проблемы, ведущие к «костылям» и неизбежному росту класса и уменьшению его красоты. В данном случае, если вам надо как-то по своему отреагировать на ошибку, вы просто реализуете протокол обработчика ошибки и инжектируете его в обработчика ответа: ничего менять в других местах вы не будете, вы расширите систему, а не модифицируете ее, что есть хороший пример Open-Close принципа с точки зрения системы. Все объекты выполняют одну свою роль: Single Responsibility Principle. Выполнение остальных принципов, думаю очевидно.

Идея заключается в том, чтобы реализовать сервис, которому мы даем запрос, говорим какую модель хотим получить в итоге, даем если нужно свои обработчики ответа, ошибок, декодирования ответа. Далее мы просто просим его послать запрос и ждем ответа.

Для достижения такой цели прекрасно подходит обобщенное программирование (Generics). Обобщать мы будем с целью получения сервиса, который успешно работает с любой моделью.

Итак, вот как выглядит наш сервис, отправляющий запрос:

final class BaseService<T: Decodable>: Service {
    typealias ResultTypeValue = T
    
    var responseHandler: HTTPResponseHandler<T>? = HTTPResponseHandler<T>()
    var request: HTTPRequestRepresentable?

    var successHandler: SuccessHandlerBlock?
    var failureHandler: FailureHandlerBlock?
    var noneHandler: (() -> ())?
    
    var requestPreparator: RequestPreparator? = BaseRequestPreparator()
    
    private var session: URLSession {
        let session = URLSession(configuration: URLSessionConfiguration.default, delegate: nil, delegateQueue: nil)
        
        return session
    }
    
    func sendRequest() -> BaseService<T>? {
        guard var request = request else {
            return nil
        }
        
        requestPreparator?.prepareRequest(&request)
        
        guard let urlRequest = request.urlRequest() else {
            return nil
        }

        session.dataTask(with: urlRequest) { [weak self] (data, response, error) in
            let response = BaseResponse(data: data, response: response, error: error)
            
            self?.responseHandler?.handleResponse(response, completion: { [weak self] (result) in
                switch result {
                case let .Value(model):
                    self?.processSuccess(model)
                case let .Error(error):
                    self?.processError(error)
                default:
                    self?.processNone()
                    break
                }
            })
        }.resume()
        
        return self
    }
    
    func onSucces(_ success: @escaping SuccessHandlerBlock) -> BaseService<T> {
        successHandler = success
        
        return self
    }
    
    func onFailure(_ failure: @escaping FailureHandlerBlock) -> BaseService<T> {
        failureHandler = failure
        
        return self
    }
    
    func onNone(_ none: @escaping () -> ()) -> BaseService<T> {
        noneHandler = none
        
        return self
    }
    
    private func processSuccess(_ model: T) {
        successHandler?(model)
        successHandler = nil
    }

    private func processError(_ error: ErrorRepresentable) {
        failureHandler?(error)
        failureHandler = nil
    }
    
    private func processNone() {
        noneHandler?()
        noneHandler = nil
    }
}

Как видно, все что он делает это подготовка запроса, отправка его с помощью Apple'вского фреймворка и передача ответа на обработку обработчику ответов.

Как вы поняли, параметр обобщенного класса T это тип итоговой модели. Знание этого типа в большей степени нужно обработчику ответа, взглянем на него:

class HTTPResponseHandler<T: Decodable>: ResponseHandler {
    typealias ResultValueType = T
    
    private var isResponseRepresentSimpleType: Bool {
        return
            T.self == Int.self ||
            T.self == String.self ||
            T.self == Double.self ||
            T.self == Float.self
    }
    
    var errorHandler: ErrorHandler = BaseErrorHandler()
    var successResponseChecker: SuccessResponseChecker = BaseSuccessResponseChecker()
    var decodingProcessor = ModelDecodingProcessor<T>()
    var nestedModelGetter: NestedModelGetter?
    
    func handleResponse(_ response: ResponseRepresentable, completion: (Result<T>) -> ()) {
        if successResponseChecker.isSuccessResponse(response) {
            processSuccessResponse(response, completion: completion)
        } else {
            processFailureResponse(response, completion: completion)
        }
    }
    
    private func processSuccessResponse(_ response: ResponseRepresentable, completion: (Result<T>) -> ()) {
        guard var data = response.data else {
            return
        }
/*
        if let nestedModelGetter = nestedModelGetter {
            if let escapedModelJSON = try? nestedModelGetter.getFrom(data) {

                if isResponseRepresentSimpleType {
                    if let result = simpleTypeUsingNestedModelGetter(from: data) {
                        completion(.Value(result))
                        
                        return
                    }
                    
                    completion(.None)
                    
                    return
                } else {
                    guard let model = escapedModelJSON[nestedModelGetter.escapedModelKey] else {
                        completion(.None)
                        
                        return
                    }
                    
                    if model is JSON {
                        guard let serializedData = try? JSONSerialization.data(withJSONObject: model, options: [])  else {
                            completion(.None)
                            
                            return
                        }
                        
                        data = serializedData
                    } else {
                        completion(.None)
                        
                        return
                    }
                }
            }
        }
*/
        guard let result = try? decodingProcessor.decodeFrom(data) else {
            completion(.None)
            
            return
        }
        
        completion(.Value(result))
    }
    
    private func simpleTypeUsingNestedModelGetter(from data: Data) -> T? {
        let getter = nestedModelGetter!
        
        guard let escapedModelJSON = try? getter.getFrom(data) else {
            return nil
        }
        
        guard let result = escapedModelJSON[getter.escapedModelKey] as? T else {
            return nil
        }
        
        return result
    }
    
    
    private func processFailureResponse(_ response: ResponseRepresentable, completion: (Result<T>) -> ()) {
        errorHandler.handleErrorResponse(response) { (error) in
            completion(.Error(error))
        }
    }
}

Я специально закомментировал некоторые строки, чтобы не отвлекать от основной реализации. Что делают эти закомментированные строки? Я реализовал возможность извлечения вложенной модели, если остально в ответе вам не нужно. Такое бывает, например в случае, когда вы запрашиваете стенку ВК и он возвращает что-то вроде:

["response": {
"items": [{"id":1, "text": "some"}, {"id":2, "text": "awesome"}],
"count": 231
}]

а вам нужны только items, в таком случае вы можете дать обработчику ошибок NestedModelGetter, который имеет проперти keyPath в виде «response.items», и он вытащить для вас вашу модель. Также в моей реализации можно достать count, то есть примитивный тип, для которого вы конечно должны дать объект, который data в этот тип преобразует.

Весь проект доступен ниже по ссылке, там вы все можете увидеть.

Также видно, что у обработчика ответа есть валидатор успешности и в случае неуспешного ответа мы отдаем ответ обработчику ошибок, базовая реализация которого выглядит у меня вот так:

struct BaseErrorHandler: ErrorHandler {
    var errorCodeHandler: ErrorCodeHandler = BaseErrorCodeHandler()
    var errorCodeGetter: ErrorCodeGetter = BaseErrorCodeGetter()
    var errorMessageGetter: ErrorMessageGetter = BaseErrorMessageGetter()
    
    func handleErrorResponse(_ response: ResponseRepresentable, completion: (ErrorRepresentable) -> ()) {
        guard let httpResponse = response.response as? HTTPURLResponse else {
            return
        }
        
        var errorMessage: String?
        var errorCode = httpResponse.statusCode
        
        if let data = response.data {
            errorMessage = errorMessageGetter.messageFromErrorData(data)
            errorCode = errorCodeGetter.errorCodeFrom(response)
        }
        
        let error = BaseError(errorCode: errorCode, message: errorMessage)
        errorCodeHandler.handleError(with: errorCode)
        
        completion(error)
    }
}

Ничего особенного.

Приведу пример модели поста стены, чтобы было понятно, как она дает себя собрать из ответа:

struct WallItem: Decodable {
    var id: Int
    var text: String
}

Модели просто реализуют протокол Decodable, и, конечно, если ключи в JSON не совпадают с именами у модели, необходимо также добавить в модель CodingKeys. Об этом всем можно почитать в документации Apple.

Также приведу пример валидатора успешного запроса для API VK:

struct VKAPISuccessChecker: SuccessResponseChecker {
    let jsonSerializer = JSONSerializer()
    
    func isSuccessResponse(_ response: ResponseRepresentable) -> Bool {
        guard let httpResponse = response.response as? HTTPURLResponse else {
            return false
        }
        
        let isSuccesAccordingToStatusCode = Range(uncheckedBounds: (200, 300)).contains(httpResponse.statusCode)
        
        guard let data = response.data else {
            return false
        }
        
        guard let json = try? jsonSerializer.serialize(data) else {
            return false
        }
        
        return isSuccesAccordingToStatusCode && !json.keys.contains("error")
    }
}

Процесс сборки сервиса для запроса стенки ВК выглядит так:

let getService = BaseService<Wall>()
getService.request = GETWallRequest()
        
let responseHandler = HTTPResponseHandler<Wall>()
responseHandler.nestedModelGetter = ResponseModelGetter.wallResponse
responseHandler.successResponseChecker = VKAPISuccessChecker()
        
getService.responseHandler = responseHandler
        
_ = getService.sendRequest()?.onSucces({ (wall) in
            print(wall)
})

Думаю, никакому адекватному разработчику не хотелось бы прописывать это в каждом контроллере. Мне тоже, поэтому завернем этот запрос и также запрос на публикацию поста в отдельный объект, который будет реализовывать следующие протоколы:

protocol WallGettable {
    func getWall(completion: @escaping (Wall) -> ())
}

protocol WallPostable {
    func postWall(with message: String)
}

typealias WallAPI = WallGettable & WallPostable

А вот его реализация:

class BasicWallAPI: WallAPI {
    lazy var getWallService: BaseService<Wall> = {
        let service = BaseService<Wall>()
        service.request = GETWallRequest()
        
        let responseHandler = HTTPResponseHandler<Wall>()
        responseHandler.nestedModelGetter = ResponseModelGetter.wallResponse
        responseHandler.successResponseChecker = VKAPISuccessChecker()
        
        service.responseHandler = responseHandler
        
        return service
    }()
    
    lazy var postService: BaseService<[String: [String: Int]]> = {
        let service = BaseService<[String: [String: Int]]>()
        
        return service
    }()

    func getWall(completion: @escaping (Wall) -> ()) {
        _ = getWallService.sendRequest()?.onSucces({ (wall) in
            completion(wall)
        })
    }

    func postWall(with message: String) {
        _ = postService.sendRequest()
    }
}

Вот мы и пришли к результату, который был показан в начале статьи. Приятным плюсом является реализация принципа Separation of Concerns, то есть контроллер будет в состоянии вызвать только те методы, которые ему необходимы и не будет знать ни о чем другом.

Пример использования

Давайте реализуем также метод для получения количества записей на стене, то есть значения поля count.

Расширим протокол WallGettable:

protocol WallGettable {
    func getWall(completion: @escaping (Wall) -> ())
    func getWallItemsCount(completion: @escaping (Int) -> ())
}

Реализуем новый метод в нашей структуре:

    lazy var getWallItemsCountService: BaseService<Int> = {
        let service = BaseService<Int>()
        service.request = GETWallRequest()
        
        let responseHandler = HTTPResponseHandler<Int>()
        responseHandler.nestedModelGetter = ResponseModelGetter.wallResponseCount
        responseHandler.successResponseChecker = VKAPISuccessChecker()
        responseHandler.decodingProcessor = IntDecodingProcessor()
        
        service.responseHandler = responseHandler
        
        return service
    }()

    func getWallItemsCount(completion: @escaping (Int) -> ()) {
        _ = getWallItemsCountService.sendRequest()?.onSucces({ (count) in
            completion(count)
        })
    }

Что из себя представляет ResponseModelGetter?

enum ResponseModelGetter: String, NestedModelGetter {
    case wallResponse = "response"
    case wallResponseItems = "response.items"
    case wallResponseCount = "response.count"
    case wallResponseFirstText = "response.items.text"
    
    var keyPath: String {
        return self.rawValue
    }
}

Вызовем новый метод:

    override func viewDidLoad() {
        super.viewDidLoad()
        
        service.getWallItemsCount { (count) in
            print("Wall items count is \(count)")
        }
    }

Получим вывод в консоль:

Wall items count is 1650

Конечно, необязательно оборачивать API всю эту логику, но это удобно, красиво и правильно (главное не свалить все методы API в один класс). При тестировании слоя на API ВК не забудьте вставить свой access_token (куда его прописывать найдете в ReqestPreparator'ах).

Детали реализации вы можете посмотреть в проекте, доступном по ссылке.

Если вам понравилась реализация, не пожалейте для нее звезды.