Quelle est votre compréhension de l'architecture REST…

REST n’est pas une architecture, mais un ensemble de principes de conception pour les systèmes distribués. Principes fondamentaux:

Client-serveur: Séparation des responsabilités. Le client demande des ressources, le serveur les fournit.
Sans état (Stateless): Le serveur ne stocke pas d’informations sur l’état du client entre les requêtes. Chaque requête du client contient toutes les informations nécessaires.
Cachable: Les clients et nœuds intermédiaires peuvent mettre en cache les réponses du serveur. Le serveur doit indiquer la possibilité de mise en cache.
Système en couches: Le client n’interagit pas nécessairement directement avec le serveur final; il peut interagir avec des couches intermédiaires (par exemple, équilibrages de charge, proxies).
Code à la demande: Capacité du serveur à fournir du code exécutable au client (par exemple, JavaScript). Rare en développement iOS.
Interface uniforme: Le principe le plus important. Définit la structure et le format d’interaction:
- Identification des ressources dans les requêtes: Les ressources sont identifiées par des URI uniques.
- Manipulation des ressources via des représentations: Le client manipule les ressources en envoyant leurs représentations (par exemple, JSON, XML) au serveur.
- Messages auto-descriptifs: Chaque message contient suffisamment d’informations pour son traitement.
- Hypermedia comme moteur de l’état de l’application (HATEOAS): Le serveur fournit des liens vers d’autres actions ou ressources dans le corps de la réponse. Permet au client de naviguer entre les états de l’application via hypermédia.

Dans les projets iOS, j’ai appliqué l’architecture RESTful en utilisant les approches suivantes:

Travail avec API: La majorité de l’interaction avec le backend se faisait via API RESTful, fournissant l’accès aux données et fonctionnalités via des méthodes HTTP (GET, POST, PUT, DELETE).

Utilisation de frameworks: J’ai utilisé activement des frameworks comme URLSession (natif) ou des tiers, comme Alamofire, pour effectuer des requêtes HTTP et traiter les réponses.

// Exemple de requête avec URLSession
let url = URL(string: "https://api.example.com/users/1")!
let task = URLSession.shared.dataTask(with: url) { data, response, error in
    guard let data = data, error == nil else {
        print("Erreur: \(error?.localizedDescription ?? "Erreur inconnue")")
        return
    }

    // On suppose que la réponse est en JSON
    if let json = try? JSONSerialization.jsonObject(with: data, options: []) {
        print(json)
    }
}
task.resume()

Traitement des données: La parsing des réponses JSON était effectuée avec JSONDecoder ou d’autres méthodes.

// Exemple de décodage de réponse JSON
struct User: Decodable {
    let id: Int
    let name: String
}

func parseUserData(data: Data) {
    let decoder = JSONDecoder()
    if let user = try? decoder.decode(User.self, from: data) {
        print("ID utilisateur: \(user.id), Nom: \(user.name)")
    } else {
        print("Échec du décodage JSON")
    }
}

Modélisation des données: Création de modèles Swift représentant les ressources reçues du serveur.
Patrons architecturaux: Intégration du travail avec API REST selon le patron architectural utilisé (MVC, MVVM, MVP, VIPER). Par exemple, en MVVM, la logique réseau se trouve souvent dans la couche de Services ou Repositories.
Caché: Utilisation de mécanismes de cache intégrés à URLSession ou implémentation de logique de cache propre pour améliorer la performance et supporter le mode hors ligne.
Gestion des erreurs: Mise en œuvre d’une gestion détaillée des erreurs provenant de l’API (par exemple, 401 Non autorisé, 404 Non trouvé), informant l’utilisateur ou prenant des actions appropriées.

Les principes d’Interface uniforme et de Sans état ont été clés dans la conception de l’interaction entre l’application iOS cliente et le backend, rendant l’API prévisible et évolutive.

Quelle est votre compréhension de l'architecture REST et comment l'avez-vous appliquée dans vos projets?