Alamofire — qu'est-ce que c'est, client HTTP en Swift et comment ça marche

Qu'est-ce qu'Alamofire ?

Alamofire est un client HTTP pour Swift créé par Alamofire Software Foundation (initialement par Mattt Thompson en 2014). La bibliothèque abstrait les détails de bas niveau d'URLSession, offrant une API propre et expressive pour les communications réseau.

La philosophie centrale d'Alamofire est la syntaxe par chaînage, où les paramètres de la requête (URL, méthode, en-têtes, paramètres, encodeur) sont transmis via des appels séquentiels. Cela rend le code plus lisible et réduit la probabilité d'erreurs liées à une configuration incorrecte d'URLRequest. L'approche déclarative permet de se concentrer sur ce qui doit être fait plutôt que sur les détails de la configuration de la connexion. Le développeur décrit le résultat souhaité et la bibliothèque se charge du travail réseau de bas niveau.

La bibliothèque est activement maintenue depuis 2014 et a traversé sept versions majeures. Alamofire 5, actuel en 2025–2026, inclut la prise en charge de Combine, async/await, des convertisseurs de réponse, EventMonitor pour le débogage et RequestInterceptor pour intercepter les requêtes. Chaque version majeure a apporté des améliorations significatives : Alamofire 4 a ajouté la prise en charge de Codable, Alamofire 5 a ajouté Combine Publishers et un système d'interception de requêtes amélioré.

L'écosystème Alamofire comprend des bibliothèques supplémentaires : AlamofireImage pour le chargement et la mise en cache des images, AlamofireNetworkActivityIndicator pour l'indicateur réseau dans la barre d'état iOS et AlamofireObjectMapper pour l'intégration avec ObjectMapper. Ces composants font d'Alamofire une pile réseau complète, et pas seulement un client HTTP.

Installation et configuration

Alamofire s'installe via Swift Package Manager (recommandé), CocoaPods ou Carthage. Dans Xcode, il suffit d'ouvrir le menu File → Add Packages, de coller l'URL du dépôt et de spécifier la version.

// Swift Package Manager — ajouter à Package.swift
dependencies: [
    .package(url: "https://github.com/Alamofire/Alamofire.git",
             from: "5.9.0")
]

// Importer dans le fichier
import Alamofire

Après l'installation, Alamofire est disponible globalement via l'espace de noms AF(abréviation d'Alamofire) sans configuration supplémentaire. La plupart des projets commencent par configurer une Session avec leurs propres paramètres — cela permet de définir une URL de base, des en-têtes par défaut, des délais d'attente et des gestionnaires de certificats TLS.

let configuration = URLSessionConfiguration.default
configuration.timeoutIntervalForRequest = 30
let session = Session(configuration: configuration)

La création d'une session personnalisée via Session(configuration:) est nécessaire lorsqu'une configuration unique est requise pour différentes parties de l'application — par exemple, une session séparée pour les téléchargements d'images avec mise en cache agressive et une autre pour les requêtes API avec authentification. La Session Alamofire accepte non seulement la configuration, mais aussi un interceptor, serverTrustManager, cachedResponseHandler et redirectHandler, offrant un contrôle total sur le comportement réseau à toutes les étapes de la requête.

Fonctionnalités principales

Alamofire fournit un large éventail de fonctions couvrant la plupart des scénarios d'interaction réseau dans les applications iOS. Examinons les principales.

Requêtes HTTP

La syntaxe de base d'une requête inclut la méthode, l'URL, les paramètres et l'encodage. Toutes les méthodes HTTP standard sont prises en charge via l'énumération HTTPMethod : get, post, put, patch, delete. Les paramètres peuvent être encodés en paramètres d'URL (URLEncoding), corps JSON (JSONEncoding) ou données multipart (MultipartFormData).

AF.request("https://api.example.com/users", method: .post,
           parameters: ["name": "Alex", "role": "developer"])
    .validate()
    .responseDecodable(of: User.self) { response in
        switch response.result {
        case .success(let user):
            print("Créé par l'utilisateur : \(user)")
        case .failure(let error):
            print("Erreur : \(error)")
        }
    }

La méthode validate() vérifie automatiquement le code d'état (200–299) et le type de contenu, retournant une erreur en cas de réponse inattendue, éliminant la vérification manuelle de statusCode. responseDecodable utilise le protocole Decodable pour la désérialisation automatique du JSON en structures Swift — cela élimine la JSONSerialization manuelle et réduit le code passe-partout lors du travail avec les API REST.

Traitement des réponses

Alamofire prend en charge plusieurs types de gestionnaires de réponse : response (données brutes), responseJSON (dictionnaire/tableau), responseString (texte), responseData (Data) et responseDecodable (modèle Decodable). Les convertisseurs de réponse peuvent être personnalisés — pour protobuf, les formats graphiques ou des protocoles personnalisés.

Téléchargement et chargement de fichiers

Pour envoyer des données au serveur, on utilise upload, qui prend en charge Data, File et MultipartFormData. Le téléchargement de fichiers volumineux s'effectue via download avec possibilité de reprise via resumeData après une interruption de connexion. Les deux opérations prennent en charge le suivi de la progression via uploadProgress et downloadProgress avec des valeurs fractionnaires de 0 à 1 pour l'affichage dans l'interface utilisateur.

Le téléchargement multipart avec Alamofire est particulièrement pratique : la méthode upload(multipartFormData:) accepte une fermeture dans laquelle les parties du formulaire sont ajoutées via append. Chaque partie peut contenir des données, un fichier ou un flux, ainsi que son propre nom et type mime. Alamofire calcule automatiquement les limites multipart et définit l'en-tête Content-Type correct, évitant au développeur de former manuellement le corps de la requête. Pour les fichiers volumineux, il est recommandé d'utiliser des fournisseurs de flux plutôt que de charger l'intégralité du fichier en mémoire — cela évite de dépasser la limite de mémoire sur les appareils mobiles aux ressources limitées. Un scénario typique consiste à envoyer l'avatar d'un utilisateur avec les données de profil dans une seule requête multipart, ce qui réduit le nombre d'appels HTTP et simplifie le traitement côté serveur.

Alamofire vs URLSession

Comparer Alamofire avec URLSession natif aide à prendre des décisions architecturales. Alamofire ne remplace pas URLSession — il se construit par-dessus et utilise les mêmes mécanismes de configuration, de mise en cache et de tâches en arrière-plan. Toutes les fonctionnalités d'URLSession sont accessibles via Alamofire, mais avec une syntaxe déclarative plus pratique.

Dans les grands projets, Alamofire réduit le code des requêtes réseau de 30 à 50 % et simplifie la gestion des erreurs. Dans les petits projets ou lorsque la taille du binaire est une contrainte stricte, l'URLSession natif est préférable en raison de l'absence de dépendances externes.

Alamofire 5 moderne s'intègre avec Combine via la propriété publishDecodable, qui renvoie un Publisher, permettant des chaînes de requêtes réactives avec gestion des erreurs et transformation des données. Pour async/await, les méthodes avec le suffixe value sont disponibles — par exemple, AF.request(url).serializingDecodable(User.self).value, rendant la syntaxe extrêmement concise et rappelant le travail avec URLSession natif. Lors de l'utilisation d'async/await, les fermetures ne sont plus nécessaires et la gestion des erreurs s'effectue via les blocs do-catch standard de Swift, simplifiant la maintenance et la lisibilité du code à long terme.

Exemples de code

Examinons un exemple plus complexe — une requête avec un intercepteur qui ajoute automatiquement un jeton d'autorisation et effectue une nouvelle tentative en cas d'erreur 401. C'est un scénario typique pour les applications avec authentification JWT.

class AuthInterceptor: RequestInterceptor {
    func adapt(_ urlRequest: URLRequest,
               for session: Session,
               completion: @escaping (Result<URLRequest, Error>) -> Void) {
        var request = urlRequest
        request.setValue("Bearer \(TokenManager.shared.token)",
                         forHTTPHeaderField: "Authorization")
        completion(.success(request))
    }

    func retry(_ request: Request,
              for session: Session,
              dueTo error: Error,
              completion: @escaping (RetryResult) -> Void) {
        guard let response = request.response,
              response.statusCode == 401
        else { return completion(.doNotRetry) }
        TokenManager.shared.refreshToken { success in
            completion(success ? .retry : .doNotRetry)
        }
    }
}

L'AuthInterceptor implémente deux protocoles : adapt (ajoute un jeton à chaque requête) et retry (tente de renouveler le jeton en cas d'erreur 401). La méthode retry vérifie le code d'état de la réponse et, si un 401 est reçu, demande un nouveau jeton via TokenManager. Après un renouvellement réussi, la requête est automatiquement réessayée.

Utilisation de l'intercepteur avec une session :

let session = Session(interceptor: AuthInterceptor())
session.request("https://api.example.com/profile")
    .responseDecodable(of: Profile.self) { response in
        print(response.result)
    }

Toutes les requêtes via cette session passent automatiquement par AuthInterceptor — le jeton est ajouté aux en-têtes, et en cas de 401, un renouvellement et une nouvelle tentative sont effectués. Cela élimine la duplication du code d'authentification dans chaque requête et centralise la logique de gestion des jetons.