1. Quels sont les principes fondamentaux d'une API REST ?
REST (Representational State Transfer) repose sur six contraintes : Client-serveur (separation des responsabilites), Stateless (chaque requete contient toute l'information necessaire), Cacheable (les reponses indiquent si elles sont cacheables), Interface uniforme (identification des ressources par URI, manipulation via representations, messages auto-descriptifs, HATEOAS), Systeme en couches (le client ne sait pas s'il communique avec le serveur final), Code on demand (optionnel, envoi de code executable). Les ressources sont identifiees par des noms (GET /users/123), pas des verbes. Les methodes HTTP (GET, POST, PUT, PATCH, DELETE) definissent les actions.
2. Quelle est la difference entre REST et GraphQL ?
REST expose des endpoints fixes retournant des structures predefinies. Problemes : over-fetching (trop de donnees) et under-fetching (pas assez, necessite des requetes supplementaires). GraphQL expose un seul endpoint avec un schema type ou le client specifie exactement les donnees souhaitees. Avantages GraphQL : requetes flexibles, un seul aller-retour reseau, schema auto-documente, types forts. Inconvenients : complexite du serveur, mise en cache plus difficile (POST uniquement), risque de requetes N+1 cote serveur, potentiel d'abus avec des requetes trop profondes. REST reste preferable pour les API simples, publiques, ou avec du caching HTTP intensif.
3. Comment concevoir les codes de statut HTTP correctement ?
2xx Succes : 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, details).
4. Expliquez les strategies d'authentification pour les API.
API Key : simple, dans un header (X-API-Key). Pas d'identite utilisateur, plutot 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 verifier cote serveur a chaque requete. Contient header, payload (claims), signature. Attention a la taille et a l'impossibilite de revocation sans blacklist. Sessions : cote serveur, necessitent un store partage pour le scaling. Recommandation : OAuth 2.0 avec JWT pour les API modernes, API Key pour les integrations 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 necessitent pas de nouvelle version. Planifier la strategie de migration pour les clients.
6. Qu'est-ce que le rate limiting et comment l'implementer ?
Le rate limiting protege l'API contre les abus et garantit une qualite de service equitable. Algorithmes : Fixed window (compteur par fenetre de temps), Sliding window (plus precis, evite les pics aux frontieres), Token bucket (tokens regeneres regulierement, autorise les bursts), Leaky bucket (debit constant). Implementation : 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. Differents tiers (free, pro, enterprise) avec des limites differentes. 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 reponses statiques. Redis pour le cache applicatif. Pagination : cursor-based (performant, stable) ou offset-based (simple). Limiter les resultats par page. Compression : gzip/brotli pour les reponses. Champs partiels : permettre au client de specifier les champs voulus (fields=name,email). Requetes batch : regrouper plusieurs operations en une requete. Connection pooling pour les bases de donnees. Index sur les colonnes filtrees et triees. Denormalisation strategique pour eviter les jointures couteuses. CDN pour les API geographiquement distribuees. Monitorer les temps de reponse au P95 et P99.
8. Expliquez les resolvers et le schema dans GraphQL.
Le schema definit le contrat de l'API avec le Schema Definition Language (SDL). Types : Query (lecture), Mutation (ecriture), Subscription (temps reel). Chaque type a des champs types (String, Int, Boolean, ID, types personnalises, listes). Le ! indique un champ non-nullable. Les resolvers sont des fonctions qui resolvent chaque champ du schema. Ils recoivent quatre arguments : parent (resultat du resolver parent), args (arguments du champ), context (donnees partagees comme l'utilisateur authentifie, le dataloader), info (metadata de la requete). Le probleme N+1 se resout avec DataLoader qui batch et cache les requetes dans une meme execution.
9. Comment documenter une API efficacement ?
Pour REST : OpenAPI/Swagger (spec en YAML/JSON, generation de documentation interactive avec Swagger UI ou Redoc). Pour GraphQL : le schema est auto-documente, utiliser les descriptions et GraphiQL/Apollo Explorer. Contenu essentiel : description de chaque endpoint, parametres (type, requis, valeurs par defaut), exemples de requete et reponse, 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 etre 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 reponses contiennent des liens vers les actions et ressources associees. Exemple : une reponse 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 malgre son elegance theorique. Les webhooks sont des callbacks HTTP : au lieu que le client poll l'API, le serveur envoie une requete HTTP POST vers une URL configuree par le client quand un evenement survient. Securisation : signature HMAC du payload, verification de l'IP source, retry avec backoff exponentiel, idempotence via un identifiant d'evenement unique.