API REST

Question 1

Qu’est-ce qu’une architecture REST et quels sont ses principes fondamentaux ?

Answer 1

REST (Representational State Transfer) est un style d’architecture pour concevoir des API web, défini par Roy Fielding en 2000. Ses principes fondamentaux sont :

Architecture client-serveur : séparation des responsabilités
Sans état (Stateless) : chaque requête contient toutes les informations nécessaires
Mise en cache : les réponses indiquent si elles sont cachables
Interface uniforme : identification des ressources par URI, manipulation via représentations, messages auto-descriptifs, et HATEOAS
Système en couches : l’architecture peut inclure des couches intermédiaires transparentes

Ces principes permettent de créer des API évolutives, performantes et maintenables qui s’intègrent naturellement avec le protocole HTTP.

Question 2

Quelle est la différence entre PUT et PATCH dans une API REST ?

Answer 2

PUT et PATCH sont deux méthodes HTTP utilisées pour modifier des ressources, mais avec des objectifs différents :

PUT est utilisé pour remplacer complètement une ressource. Si certains champs ne sont pas spécifiés dans la requête, ils seront réinitialisés à leurs valeurs par défaut ou supprimés. PUT est idempotent, ce qui signifie que plusieurs requêtes identiques produisent le même résultat qu’une seule.
PATCH est utilisé pour appliquer des modifications partielles à une ressource. Seuls les champs spécifiés dans la requête sont modifiés, les autres restent inchangés. PATCH n’est pas nécessairement idempotent, car des opérations successives peuvent avoir des effets cumulatifs.

Par exemple, si nous avons un produit avec {nom: “Téléphone”, prix: 500, stock: 10}, un PUT avec {nom: “Smartphone”, prix: 600} définirait la ressource à {nom: “Smartphone”, prix: 600} (sans stock), tandis qu’un PATCH avec les mêmes données donnerait {nom: “Smartphone”, prix: 600, stock: 10}.

Question 3

Comment gérez-vous les erreurs dans une API REST ?

Answer 3

Pour gérer les erreurs dans une API REST, j’applique ces principes :

1.J’utilise les codes de statut HTTP appropriés pour indiquer le type d’erreur :

400 Bad Request pour les erreurs de validation
401 Unauthorized pour les problèmes d’authentification
403 Forbidden pour les problèmes d’autorisation
404 Not Found quand une ressource n’existe pas
409 Conflict pour les conflits d’état
500 Internal Server Error pour les erreurs serveur

2.Je renvoie un corps de réponse JSON structuré avec des informations sur l’erreur :
{
“status”: 400,
“message”: “Validation échouée”,
“details”: [
{“field”: “email”, “error”: “Format d’email invalide”}
]
}

3. J’utilise une gestion d’erreur cohérente à travers toute l’API, souvent avec des middlewares globaux dans Express qui capturent et formatent les erreurs de manière uniforme.
   4.Je documente clairement les erreurs possibles pour chaque endpoint de l’API.

Cette approche permet aux consommateurs de l’API de traiter les erreurs de manière programmatique et d’offrir une meilleure expérience utilisateur.

Question 4

Comment implémentez-vous la pagination dans une API REST ?

Answer 4

Pour implémenter la pagination dans une API REST, j’utilise généralement deux approches :

1. Pagination basée sur l’offset et la limite :

Paramètres de requête : /api/products?offset=20&limit=10
Simple à implémenter
Efficace pour les petits ensembles de données
Exemple de réponse :
jsonCopier{
“data”: […],
“pagination”: {
“total”: 100,
“offset”: 20,
“limit”: 10,
“next”: “/api/products?offset=30&limit=10”,
“previous”: “/api/products?offset=10&limit=10”
}
}

2. Pagination basée sur le curseur :

Paramètres de requête : /api/products?cursor=xyz&limit=10
Plus performante pour les grands ensembles de données
Meilleure pour les données qui changent fréquemment
Exemple de réponse :
jsonCopier{
“data”: […],
“pagination”: {
“next_cursor”: “abc123”,
“has_more”: true
}
}

Dans l’implémentation, je m’assure de :

Définir une limite par défaut raisonnable
Imposer une limite maximale pour éviter les surcharges
Inclure des métadonnées de pagination dans la réponse
Fournir des liens vers les pages suivantes/précédentes (conforme à HATEOAS)

Question 5

Comment assurez-vous la sécurité d’une API REST ?

Answer 5

Pour sécuriser une API REST, j’implémente plusieurs niveaux de protection :

1. Transport sécurisé :
   Utilisation systématique de HTTPS/TLS
   Configuration des en-têtes HTTP de sécurité (Strict-Transport-Security, X-Content-Type-Options)
2. Authentification :
   Tokens JWT pour l’authentification sans état
   Gestion sécurisée des JWT (expiration courte, refresh tokens)
   OAuth 2.0 pour l’authentification externe si nécessaire
3. Autorisation :
   Contrôles d’accès basés sur les rôles (RBAC)
   Validation des permissions au niveau des ressources
   Principe du moindre privilège

4.Protection contre les attaques courantes :
Validation rigoureuse des entrées pour prévenir les injections
Protection CSRF pour les API consommées par des navigateurs
Configuration correcte de CORS
Rate limiting pour prévenir les attaques par force brute

5Gestion des données sensibles :
Ne jamais exposer de données sensibles dans les URI
Filtrage des données sensibles des réponses
Hachage des mots de passe et chiffrement des données sensibles

Pour l’implémentation concrète avec Express, j’utilise des middlewares comme helmet pour les en-têtes de sécurité, express-rate-limit pour le rate limiting, et des middlewares personnalisés pour l’authentification et l’autorisation.