Гибкий сетевой слой в 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{ case Value(T) case Error(ErrorRepresentable) case None } protocol ResponseHandler { associatedtype ResultValueType func handleResponse(_ response: ResponseRepresentable, completion: (Result ) -> ()) } - Модель, в которую мы хотим преобразовать ответ
Этот слой построен с учетом прекрасной возможности в Swift 4, которая предоставила нам такой протокол как Decodable, при реализации которого ваша модель будет самостоятельно (почти) создана из пришедшего ответа.
Отправитель запроса нуждается в:
- Подготовителе запроса
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? { get set }
func sendRequest() -> Self?
}
Себя мы будем возвращать для реализации Method Chaining’а.
Как видите я только описал протоколы, по которым вся эта система будет общаться с объектами внутри системы. Это дает нам возможность контролировать любой нужный нам этап, просто инжектировав свою реализацию протокола.
Нередко бывает так, что для более чем одного запроса при ошибке приходит один и тот же код, но означает он для них совершенно разное. Когда сервис — один большой объект, который все сам и обрабатывает, возникают проблемы, ведущие к «костылям» и неизбежному росту класса и уменьшению его красоты. В данном случае, если вам надо как-то по своему отреагировать на ошибку, вы просто реализуете протокол обработчика ошибки и инжектируете его в обработчика ответа: ничего менять в других местах вы не будете, вы расширите систему, а не модифицируете ее, что есть хороший пример Open-Close принципа с точки зрения системы. Все объекты выполняют одну свою роль: Single Responsibility Principle. Выполнение остальных принципов, думаю очевидно.
Идея заключается в том, чтобы реализовать сервис, которому мы даем запрос, говорим какую модель хотим получить в итоге, даем если нужно свои обработчики ответа, ошибок, декодирования ответа. Далее мы просто просим его послать запрос и ждем ответа.
Для достижения такой цели прекрасно подходит обобщенное программирование (Generics). Обобщать мы будем с целью получения сервиса, который успешно работает с любой моделью.
Итак, вот как выглядит наш сервис, отправляющий запрос:
final class BaseService: Service {
typealias ResultTypeValue = T
var responseHandler: HTTPResponseHandler? = HTTPResponseHandler()
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? {
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 {
successHandler = success
return self
}
func onFailure(_ failure: @escaping FailureHandlerBlock) -> BaseService {
failureHandler = failure
return self
}
func onNone(_ none: @escaping () -> ()) -> BaseService {
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: 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()
var nestedModelGetter: NestedModelGetter?
func handleResponse(_ response: ResponseRepresentable, completion: (Result) -> ()) {
if successResponseChecker.isSuccessResponse(response) {
processSuccessResponse(response, completion: completion)
} else {
processFailureResponse(response, completion: completion)
}
}
private func processSuccessResponse(_ response: ResponseRepresentable, completion: (Result) -> ()) {
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) -> ()) {
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()
getService.request = GETWallRequest()
let responseHandler = HTTPResponseHandler()
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 = {
let service = BaseService()
service.request = GETWallRequest()
let responseHandler = HTTPResponseHandler()
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) -> ())
}
Реализуем новый метод в нашей структуре:
Но сначала вынесем сборку сетевого модуля в отдельный объект Builder.
protocol APIBuilder {
associatedtype ResultType: Decodable
func buildAPI(for request: HTTPRequestRepresentable,
decodingProcessor: ModelDecodingProcessor?,
nestedModelGetter: NestedModelGetter?) -> BaseService
}
class VKAPIBuilder: APIBuilder {
typealias ResultType = T
func buildAPI(for request: HTTPRequestRepresentable,
decodingProcessor: ModelDecodingProcessor? = nil,
nestedModelGetter: NestedModelGetter? = nil) -> BaseService {
let service = BaseService()
service.request = request
let responseHandler = HTTPResponseHandler()
responseHandler.nestedModelGetter = nestedModelGetter
responseHandler.successResponseChecker = VKAPISuccessChecker()
responseHandler.errorHandler.errorMessageGetter = VKAPIErrorMessageGetter()
responseHandler.errorHandler.errorCodeGetter = VKAPIErrorCodeGetter()
if let decodingProcessor = decodingProcessor {
responseHandler.decodingProcessor = decodingProcessor
}
service.responseHandler = responseHandler
return service
}
}
lazy var getWallItemsCountService: BaseService = {
let apiBuilder = VKAPIBuilder()
return apiBuilder.buildAPI(for: GETWallRequest(), decodingProcessor: IntDecodingProcessor(), nestedModelGetter: ResponseModelGetter.wallResponseCount)
}()
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’ах).
Детали реализации вы можете посмотреть в проекте, доступном по ссылке.
Если вам понравилась реализация, не пожалейте для нее звезды.
