# Custom Response Handler in Alamofire

![alamofire_logo.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1587884747300/jN30RDaEt.png)

[Alamofire](https://github.com/Alamofire/Alamofire) is an elegant HTTP networking library de facto in iOS development; perhaps in the same league as [Retrofit](https://square.github.io/retrofit/) in Android programming. It’s built to be asynchronous from ground up as it uses Apple’s [URL loading system](https://developer.apple.com/documentation/foundation/url_loading_system/) thus full of handlers (check out [RxAlamofire](https://github.com/RxSwiftCommunity/RxAlamofire) to enjoy an even nicer api for your networking needs).


# Making a Request

_Alamofire 5_ has a new namespace, **AF**, that encapsulates all of its request methods. Thus to make a get request, prefix your `request` method with `AF` (this was previously available in the global namespace).

![code_1.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1587884822967/jz8mESXkD.png)

# Handling Response

The `request` method returns a `DataRequest` object which handles in-memory data download. When a request is done, the parent `Request` class has a `finish` method invoked to start registered response serializers. The serializers adopt the `ResponseSerializer` protocol which is a composition of `DataResponseSerializerProtocol` (to handle data response) and the `DownloadResponseSerializerProtocol` (to handle download response). Some of the built in serializers are:

*   DataResponseSerializer
*   StringResponseSerializer
*   JSONResponseSerializer
*   DecodableResponseSerializer

Out of the box, Alamofire has 6 response handlers that utilize these serializers to hand you a serialized response. They are:

*   Generic handler — unserialized response
*   Serializer handler — serializes response using the provided serializer
*   Data handler — serializes response into Foundations’ `Data` struct
*   String handler — yields a `String` struct
*   JSON handler — uses Foundation’s JSONSerialization — yields `Any`
*   Decodable handler — serializes into a`Decodable` type

Here’s a signature to add a handler for JSON serialized response:

![code_2.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1587884855647/qhVlOiUjI.png)

# The Need

Ignoring network and server errors, api calls typically have a response and Alamofire treats a completed network request as successful by default. (The library can also handle an `EmptyResponse`).`DataRequest` can take a validation closure to determine if the response is interpreted as an error (based on an unacceptable status code, incorrect MIME type or the given closure).

Imagine we are login in a user on an iOS app. The api is documented to give us back a `Token` object when the credentials are valid or a custom `APIError` object otherwise. If our `Token` struct conforms to the `Decodable` protocol, we can use the `responseDecodable` handler to receive a decoded `Token` object from the response.

![code_3.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1587884921357/eJGqs4UfU.png)

*JWT token object*

The login request (request payload omitted) could be made as follows.

![code_4.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1587884960867/X5IhF7mTt.png)

If the credentials provided were valid, the response variable is of type `AFDataResponse<Token>` which is a typealias for `DataResponse<Token, AFError>` where `AFError` is a custom error type by Alamofire. What if the credentials were invalid? How do we receive the decoded `APIError` object?


![code_5.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1587884989796/0k_w6Y0oD.png)

If `APIError` conforms to the `Decodable` protocol, as shown below, we could write a custom serializer and handler that returns to us a `Result<Token, APIError>.`

# Custom Serializer

To write a custom data serializer, you write a class that conforms to the `DataResponseSerializerProtocol.` The protocol is defined as follows:

![code_6.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1587885013771/Y4Tyh_LeH.png)

> Note that to handle disk downloads as well, your custom serializer should also adopt the `DownloadResponseSerializerProtocol`.

As noted above, Alamofire has an inbuilt decodable data serializer. We create a custom `TwoDecodableResponseSerializer` that uses a composition of `DataResponseSerializers`, one for each type we want decodable. After a short ceremony of making sure the response is even valid for decoding, we invoke either serializer conditionally. I pass in a _HTTP status cod_e to determine when to invoke the `APIError` serializer.

%[https://gist.github.com/charlesmuchene/afb68afb136f4dcba39b5432cd6ab10c]

# Custom Handler

A custom handler is straight forward. It uses the serializer we’ve written above. I’ve made it generic to accept any type that is `Decodable`.

%[https://gist.github.com/charlesmuchene/2fa95caf9eda6904717dd8bc94254d9c]

And we use it as shown below:

%[https://gist.github.com/charlesmuchene/0687156ed005bfa558323153a49e87fb]

* * *

And that’s it.

The [documentation](https://github.com/Alamofire/Alamofire/blob/master/Documentation/AdvancedUsage.md#creating-a-custom-response-serializer) has a section on creating a custom serializer (for your specific type of data). Happy coding.

# Reading

%[https://github.com/Alamofire/Alamofire/blob/master/Documentation/Usage.md]

%[https://developer.apple.com/documentation/foundation/url_loading_system]