API application mobile : REST, GraphQL et bonnes pratiques

REST vs GraphQL : quel paradigme choisir

Les deux paradigmes dominants pour les API mobiles sont REST et GraphQL. Chacun répond à des besoins différents et offre des avantages spécifiques selon le type d'application et la complexité des données.

REST : le standard éprouvé

REST (Representational State Transfer) est le paradigme le plus répandu pour les API web et mobiles. Il repose sur des conventions simples : chaque ressource (utilisateur, produit, commande) est accessible via une URL unique, et les opérations standard (création, lecture, mise à jour, suppression) correspondent aux méthodes HTTP (POST, GET, PUT/PATCH, DELETE). REST est simple à comprendre, à implémenter et à documenter. La majorité des développeurs le maîtrisent et les outils de débogage sont nombreux. Pour la plupart des applications mobiles avec des modèles de données classiques, REST est le choix le plus pragmatique.

GraphQL : la flexibilité des requêtes

GraphQL, développé par Meta, permet au client de demander exactement les données dont il a besoin, ni plus ni moins. Au lieu de multiples endpoints REST, un seul endpoint reçoit une requête qui décrit précisément la structure des données attendues. Cette approche résout deux problèmes récurrents de REST : le over-fetching (recevoir plus de données que nécessaire) et le under-fetching (devoir faire plusieurs requêtes pour obtenir toutes les données d'un écran). GraphQL est particulièrement pertinent pour les applications avec des interfaces complexes qui affichent des données provenant de plusieurs entités sur un même écran.

Authentification et sécurité des API

La sécurité de vos API est cruciale : elles exposent vos données et votre logique métier au réseau. Une API non sécurisée est une porte ouverte aux attaques et aux fuites de données.

JWT : le standard d'authentification mobile

Le JSON Web Token (JWT) est le mécanisme d'authentification le plus utilisé pour les API mobiles. Le principe est simple : lors de la connexion, le serveur génère un token signé contenant l'identité de l'utilisateur et ses permissions. L'application mobile stocke ce token de manière sécurisée (Keychain sur iOS, Keystore sur Android) et l'envoie dans l'en-tête Authorization de chaque requête API. Le serveur vérifie la signature du token sans avoir besoin de consulter une base de données de sessions, ce qui améliore les performances. Le token a une durée de vie limitée, généralement de 15 minutes à une heure, et un refresh token permet d'en obtenir un nouveau sans redemander les identifiants de l'utilisateur.

OAuth 2.0 et authentification sociale

OAuth 2.0 est le protocole standard pour l'authentification via des fournisseurs tiers (Google, Apple, Facebook). Il permet aux utilisateurs de se connecter à votre application sans créer de mot de passe, en utilisant leur compte existant. L'implémentation de Sign in with Apple est obligatoire pour les applications iOS qui proposent une connexion sociale. Le flux OAuth pour les applications mobiles utilise le PKCE (Proof Key for Code Exchange), une extension qui sécurise le processus en empêchant l'interception du code d'autorisation par une application malveillante.

HTTPS obligatoire et certificate pinning

Toute communication entre l'application mobile et l'API doit être chiffrée en HTTPS. Apple et Google imposent cette règle sur leurs plateformes respectives. Pour renforcer la sécurité, le certificate pinning consiste à vérifier que le certificat SSL du serveur correspond à celui attendu par l'application, empêchant les attaques de type man-in-the-middle même si l'attaquant dispose d'un certificat valide. Cette technique est recommandée pour les applications manipulant des données sensibles comme les données bancaires ou médicales.

Pagination, cache et optimisation des performances

La performance d'une API impacte directement l'expérience utilisateur de votre application mobile. Chaque milliseconde de latence supplémentaire dégrade l'impression de fluidité. Voici les techniques essentielles pour optimiser vos API.

Pagination efficace

Ne renvoyez jamais la totalité d'une collection en une seule requête. La pagination est indispensable pour les listes de données (produits, messages, notifications). Deux approches principales existent. La pagination par offset (page=2&limit=20) est simple mais pose des problèmes de cohérence quand les données changent entre deux pages. La pagination par curseur (after=abc123&limit=20) est plus robuste : elle utilise un identifiant unique comme point de repère, garantissant que l'utilisateur ne verra jamais de doublon ou de contenu manquant. Pour les applications mobiles avec du scroll infini, la pagination par curseur est recommandée.

Stratégie de cache

Le cache réduit le nombre de requêtes réseau et améliore la réactivité perçue par l'utilisateur. Côté API, utilisez les en-têtes HTTP de cache (Cache-Control, ETag, Last-Modified) pour indiquer au client quelles réponses peuvent être mises en cache et pour combien de temps. Côté application mobile, implémentez un cache local qui affiche les données en cache immédiatement puis les rafraîchit en arrière-plan (pattern stale-while-revalidate). Cette technique donne une impression de rapidité instantanée même sur des connexions lentes. Côté serveur, Redis permet de mettre en cache les requêtes fréquentes pour réduire la charge sur la base de données.

Compression et optimisation de la payload

Sur mobile, la bande passante est précieuse et variable. Activez la compression gzip ou brotli sur vos réponses API pour réduire leur taille de 60 à 80 pour cent. Limitez les champs retournés au strict nécessaire : n'incluez pas de données inutiles pour l'écran qui les consomme. Pour les images, renvoyez des URLs de versions optimisées pour mobile plutôt que les originaux haute résolution. Ces optimisations réduisent la consommation de données mobiles et améliorent les temps de chargement, en particulier sur les réseaux 3G ou les connexions dégradées.

Versioning, documentation et rate limiting

Une API bien gérée sur le long terme nécessite des pratiques rigoureuses de versioning, de documentation et de protection contre les abus.

Versioning de l'API

Contrairement à une application web où tous les utilisateurs accèdent à la même version, une application mobile installée sur les appareils des utilisateurs ne se met pas à jour instantanément. Certains utilisateurs utilisent encore une ancienne version de l'application pendant des mois après une mise à jour. Votre API doit donc supporter plusieurs versions simultanément. L'approche la plus courante est le versioning par URL (api.exemple.com/v1/users, api.exemple.com/v2/users). Maintenez au minimum deux versions actives : la version actuelle et la précédente. Communiquez les dates de dépréciation suffisamment à l'avance et incluez des en-têtes d'avertissement dans les réponses des versions obsolètes.

Documentation vivante

Une API non documentée est une API inutilisable par quiconque n'en est pas l'auteur original. Utilisez des outils de documentation automatique comme Swagger/OpenAPI pour REST ou GraphQL Playground pour GraphQL. La documentation doit inclure pour chaque endpoint : la description, les paramètres attendus, les exemples de requêtes et de réponses, les codes d'erreur possibles et les exigences d'authentification. Les outils modernes génèrent cette documentation à partir du code lui-même, ce qui garantit qu'elle reste à jour.

Rate limiting et protection contre les abus

Le rate limiting limite le nombre de requêtes qu'un client peut envoyer dans un intervalle de temps donné. Cette protection est essentielle pour éviter les abus, les attaques par déni de service et la surcharge accidentelle. Une implémentation typique autorise 100 à 1 000 requêtes par minute par utilisateur authentifié, avec des limites plus strictes pour les endpoints sensibles comme l'authentification ou la création de compte. Les en-têtes de réponse doivent indiquer les limites, le nombre de requêtes restantes et le temps avant réinitialisation, pour que l'application mobile puisse adapter son comportement en conséquence.