1. Quels sont les principes fondamentaux d'une API REST ?
REST (Representational State Transfer) repose sur six contraintes : Client-serveur (séparation des responsabilités), Stateless (chaque requête contient toute l'information nécessaire), Cacheable (les réponses indiquent si elles sont cacheables), Interface uniforme (identification des ressources par URI, manipulation via representations, messages auto-descriptifs, HATEOAS), Système en couches (le client ne sait pas s'il communique avec le serveur final), Code on demand (optionnel, envoi de code exécutable). Les ressources sont identifiées par des noms (GET /users/123), pas des verbes. Les méthodes HTTP (GET, POST, PUT, PATCH, DELETE) définissent les actions.
2. Quelle est la différence entre REST et GraphQL ?
REST expose des endpoints fixes retournant des structures prédéfinies. Problèmes : over-fetching (trop de données) et under-fetching (pas assez, nécessite des requêtes supplémentaires). GraphQL expose un seul endpoint avec un schéma type ou le client specifie exactement les données souhaitees. Avantages GraphQL : requêtes flexibles, un seul aller-retour réseau, schéma auto-documente, types forts. Inconvénients : complexité du serveur, mise en cache plus difficile (POST uniquement), risque de requêtes N+1 cote serveur, potentiel d'abus avec des requêtes trop profondes. REST reste préférable pour les API simples, publiques, ou avec du caching HTTP intensif.
3. Comment concevoir les codes de statut HTTP correctement ?
2xx Succès : 200 (OK, avec body), 201 (Created, POST reussi), 204 (No Content, DELETE reussi). 3xx Redirection : 301 (Moved Permanently), 304 (Not Modified, cache valide). 4xx Erreur client : 400 (Bad Request, validation echouee), 401 (Unauthorized, non authentifie), 403 (Forbidden, pas les droits), 404 (Not Found), 409 (Conflict, ex: doublon), 422 (Unprocessable Entity, semantiquement invalide), 429 (Too Many Requests, rate limit). 5xx Erreur serveur : 500 (Internal Server Error), 502 (Bad Gateway), 503 (Service Unavailable). Toujours retourner un body d'erreur structure (code, message, détails).
4. Expliquez les stratégies d'authentification pour les API.
API Key : simple, dans un header (X-API-Key). Pas d'identité utilisateur, plutôt pour l'identification d'application. OAuth 2.0 : standard pour l'autorisation deleguee. Flows : Authorization Code (web apps), Client Credentials (machine-to-machine), PKCE (mobile/SPA). JWT (JSON Web Tokens) : token auto-contenu signe, pas besoin de vérifier cote serveur à chaque requête. Contient header, payload (claims), signature. Attention à la taille et à l'impossibilite de revocation sans blacklist. Sessions : cote serveur, nécessitent un store partage pour le scaling. Recommandation : OAuth 2.0 avec JWT pour les API modernes, API Key pour les intégrations simples.
5. Comment versionner une API ?
Quatre approches : URL path (/v1/users, /v2/users) — la plus courante, simple et explicite. Header personnalise (Api-Version: 2) — URL propre mais moins visible. Accept header (Accept: application/vnd.myapi.v2+json) — plus RESTful mais complexe. Query parameter (?version=2) — simple mais pollue l'URL. Bonnes pratiques : supporter N-1 au minimum, communiquer la deprecation via headers (Sunset, Deprecation), documenter les changements (changelog), ne jamais casser une version existante. Les changements non-breaking (ajout de champs) ne nécessitent pas de nouvelle version. Planifier la stratégie de migration pour les clients.
6. Qu'est-ce que le rate limiting et comment l'implémenter ?
Le rate limiting protege l'API contre les abus et garantit une qualité de service equitable. Algorithmes : Fixed window (compteur par fenetre de temps), Sliding window (plus précis, evite les pics aux frontieres), Token bucket (tokens regeneres régulièrement, autorise les bursts), Leaky bucket (debit constant). Implémentation : middleware avec Redis pour le comptage distribue. Headers standards : X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After. Retourner 429 Too Many Requests avec ces headers. Différents tiers (free, pro, enterprise) avec des limites différentes. Rate limit par IP, par API key, ou par utilisateur selon le cas.
7. Comment optimiser les performances d'une API ?
Caching : Cache-Control headers, ETags, CDN pour les réponses statiques. Redis pour le cache applicatif. Pagination : cursor-based (performant, stable) ou offset-based (simple). Limiter les résultats par page. Compression : gzip/brotli pour les réponses. Champs partiels : permettre au client de spécifier les champs voulus (fields=name,email). Requêtes batch : regrouper plusieurs opérations en une requête. Connection pooling pour les bases de données. Index sur les colonnes filtrees et triees. Dénormalisation stratégique pour éviter les jointures coûteuses. CDN pour les API geographiquement distribuees. Monitorer les temps de réponse au P95 et P99.
8. Expliquez les resolvers et le schéma dans GraphQL.
Le schéma définit le contrat de l'API avec le Schéma Définition Language (SDL). Types : Query (lecture), Mutation (écriture), Subscription (temps réel). Chaque type à des champs types (String, Int, Boolean, ID, types personnalisés, listes). Le ! indique un champ non-nullable. Les resolvers sont des fonctions qui resolvent chaque champ du schéma. Ils reçoivent quatre arguments : parent (résultat du resolver parent), args (arguments du champ), context (données partagees comme l'utilisateur authentifie, le dataloader), info (metadata de la requête). Le problème N+1 se résout avec DataLoader qui batch et cache les requêtes dans une même exécution.
9. Comment documenter une API efficacement ?
Pour REST : OpenAPI/Swagger (spec en YAML/JSON, génération de documentation interactive avec Swagger UI ou Redoc). Pour GraphQL : le schéma est auto-documente, utiliser les descriptions et GraphiQL/Apollo Explorer. Contenu essentiel : description de chaque endpoint, paramètres (type, requis, valeurs par défaut), exemples de requête et réponse, codes d'erreur possibles, guide d'authentification, exemples de code dans plusieurs langages, changelog des versions. Outils : Postman Collections pour les exemples interactifs, readme.com ou Mintlify pour la documentation hebergee. La documentation doit être generee depuis le code pour rester synchronisee.
10. Qu'est-ce que HATEOAS et les webhooks ?
HATEOAS (Hypermedia As The Engine Of Application State) est un principe REST ou les réponses contiennent des liens vers les actions et ressources associees. Exemple : une réponse GET /orders/123 inclut des liens pour payer, annuler, ou voir les produits. Le client decouvre l'API dynamiquement sans URL hardcodees. Peu utilise en pratique malgré son elegance théorique. Les webhooks sont des callbacks HTTP : au lieu que le client poll l'API, le serveur envoie une requête HTTP POST vers une URL configurée par le client quand un événement survient. Sécurisation : signature HMAC du payload, vérification de l'IP source, retry avec backoff exponentiel, idempotence via un identifiant d'événement unique.