Alamofire: Feature Request - Flag to ask the response.data be converted even if validate fails.

[tobiasoleary]

An API I'm using will sometimes pass back an error message as JSON with additional information on why the request failed.

Currently I have to implement turning the NSData in response.data into a JSONDictionary when validation fails.

It would be convient for me to have Alamofire take care of this.

I would like a way to flag requests individual and/or globally to force Alamofire to attempt to convert the response.data using the same serializer type as I would have used on the response data even if the validate method fails?

I believe in the 1.0 or 2.0 version of Alamofire you could still get a converted object from result.value even if validation failed. It would be nice to have that ability again, so I'm not implementing the same logic that already exists in Alamofire's ResponseSerializers.

Thank you for your time and I hope you consider this request.

[gchaturvedi]

👍

[cnoon]

Thank you for the feature request @tobiasoleary!

While I understand where you're coming from, I don't think that's quite how we want to try to handle that case. If validation is failing, then validation is what should generate the error causing your response serializer to not be run b/c an error had already occurred. What this means is that if you encounter a validation error, you should extract the error message from the server data directly in the validation closure. This is not currently possible in Alamofire 3 unless you write an extension on Request.

In Alamofire 4, we've made it easier to parse errors out of the server data if necessary by adding the data or temporaryURL and destinationURL to the respective DataRequest or DownloadRequest validation closures. More details can be found in the migration guide. What this ultimately allows you to do is:

Alamofire.request(urlString)
    .validate { request, response, data in
        guard let data = data else { return .failure(customError) }

        // 1) Validate the response to make sure everything looks good
        // 2) If validation fails, you can now parse the error message out of the
        //    data if necessary and add that to your custom error if you wish.

        return .success
    }
    .response { response in
        debugPrint(response)
    }

If you do share the exact same response serializer to parse out the error message as you use in the response handler, then you can just reuse the serializer in the validation failure case. In many cases though the payload for the failure will be different than the success so you'd need to use different parsing logic.

Hopefully that helps clarify things and get you pointed in the right direction.

Cheers. 🍻

[cesar-oyarzun-m]

@gchaturvedi do you have an example how to get the error from the server, do I have to deserialize the data ?