Содержание:
- ChainConfiguratorNode
- ModelInputNode
- VoidInputNode
- DTOMapperNode
- Сборка запроса
- RequestCreatorNode
- TechnicaErrorMapperNode
- RequestSenderNode
- ResponseProcessorNode
- ResponseDataPreprocessorNode
- ResponseHttpErrorProcessorNode
- ResponseDataParserNode
- AborterNode
- AccessSafe
- HeaderInjectorNode
- LoadIndicatableNode
Является Generic-узлом (Input и Output не ограничены)
Этот узел встраивается одним из первых (желательно самым первым) в цепочку узлов. Он вызывает следующий узел в backround
очереди, а после того, как вся цепочка отработала - диспатчит ответ на main
.
Такое поведение определено по-умолчанию. При желании можно конфигурировать очереди.
У этого узла есть ограничение where Input: DTOEncodable, Output: DTODecodable
Это означает, что на вход он может получить только такую модель, которая в дальнейшем может быть преобразована в DTO, а на ее выходе может быть только та модель, которая может быть получена из DTO.
Следующий узел должен обязательно иметь следующую сигнатуру: Node<Input.DTO, Output.DTO>
Таким образом этот узел конвертирует входную модель в DTO Передает ее следующему узлу, а затем конвертирует ответ из DTO в нужную модель.
Этот узел похож на ModelInputNode
за исключением того, что входной параметр этого узла Void
.
Может быть использован просто для упрощения интерфейса.
Этот узел схож с ModelInputNode
, с той лишь разницей, что он ковертирует DTO в Raw (наприме в Json)
Эти узлы используются для первоначальной сборки запроса. Так как библиотека не привязана к работе с обычным HTTP подходом, то нельзя явно указывать на добавление хедеров к запросу. К примеру у gRPC за это отвечает другой API.
Это множество состоит из следующих узлов:
MetadataConnectorNode - Задача этого узла - абстрагировать процесс добавления заголовков к запросу.
RequestRouterNode - Задача этого узла - абстрагировать процесс добавления маршрута к эндпоинту.
URLQueryInjectorNode - Задача этого узла добавлять URL-Query компонент к URL запроса.
RequstEncoderNode - Задача этого узла - абстрагировать процесс указания кодировки данных для запроса.
UrlRequestTrasformatorNode Этот узел занимается конструированием запроса для классического HTTP подхода. Он получает данные, сформированные с помощью предыдущих узлов и формирует модель данных для создания обычного HTTP запроса
Этот узел просто создает HTTP запрос с помощью Alamofire и передает его дальше на обработку.
Этот узел ничего не делает с входными данными, но преобразует выходные. В случае, если дальнейшая цепочка завершилась с ошибкой, то он проверяет, является ли ошибка системной (таймаут, отстуствие интернета и т.п) и если да, то преобразует ее в собственную ошибку и прокидывает дальше. Если ошибка не подошла под описанием системной, то она пробрасывается без изменения.
Список обрабатываемых системных ошибок:
- noInternetConnection
- timeout
- cantConnectToHost
П.C. Ошибка считается системной, так как является ответом траспортного уровня системы на определенную неисправность.
Этот узел просто отправляет запрос и передает управление следующему узлу. Больше ничего не делает.
Этот узел занимается первичной обработкой ответа. В случае, если вопрос завершился с ошибкой (например, нет интернета), то он обрывает цепочку и пробрасывает ошибку наверх (не касается ошибки о пустоте тела ответа, которая появилась в последнем релизе Alamofire) Если запрос отработал успешно, то передает его результат следующему узлу.
Задача этого узла заключается в том, чтобы в случае, если код ответа 204 (no content) продолжить выполнение цепочки с пустым Json.
Этот узел мапит HTTP ошибки. В случае, если код ответа содержит известные этому узлу коды, то он прекращает выполнение цепочки и возращает ошибку.
Известные коды ошибок и их маппинг:
400 -> HttpError.badRequest
401 -> HttpError.unauthorized
403 -> HttpError.forbidden
404 -> HttpError.notFound
500 -> HttpError.internalServerError
Задачей этого узла является парсинг тела ответа в Json. Здесь предусмотрены различные случаи состояния Json объекта. В случае, если в ответе приходит не JsonObject, а JsonArray, то этот узел так же успешно парсит данные.
Этот узел позволяет отменить запрос. Он держит указатель на узел, который занимается отправкой запроса и при необходимости отменяет его.
Эту группа узлов необходима для обновления токена в том случае, если он "протух". Принцип работы сводится к тому, что в случае, если на запрос вернулся 401 или 403 код, то запрос сохраняется, все отальные запросы преостанавливаются, уходит запрос на обновление токена, затем, в случае успеха первый запрос повторяется, а остальные "размораживаются".
Этот узел обрабатывает результат выполнения цепочки. Если в итоге произшла ошибка доступа, то он передает управление TokenRefresherNode
Этот узел "замораживает" запросы до тех пор, пока не обновится токен. А затем, в зависимости от результата обновления либо возвращает ошибку либо "размораживает" запросы.
Этот узел может быть использован для того, чтобы подставлять в запрос какие-то кастомные хедеры. Например локаль или что-то еще.
Этот узел используется для того, чтобы отображать Load indicator в статус баре с того момента как был отправлен запрос и до момента его обработки.