API Restful Flashcards

Question 1

Q

Qu’est-ce qu’une API RESTful ?

Answer

A

Une API RESTful est une interface de programmation qui respecte les principes de l’architecture REST (Representational State Transfer) et permet à différents systèmes de communiquer via HTTP.

Analogie : C’est comme un serveur au restaurant : vous passez une commande (requête HTTP) claire et standardisée, et le serveur vous rapporte exactement ce que vous avez demandé (réponse).

Exemple :
```
GET /api/users/123
→ Récupère l’utilisateur 123

POST /api/users
Body: { “name”: “Alice” }
→ Crée un nouvel utilisateur
```

Pourquoi : REST utilise les standards HTTP existants, ce qui rend l’API universellement compatible et facile à comprendre.

Question 2

Q

Quel est le mnémonique pour se rappeler des opérations REST ?

Answer

A

CRUD-MAP

CRUD pour les opérations :
- Create : POST - Créer une nouvelle ressource
- Read : GET - Récupérer une ressource
- Update : PUT/PATCH - Modifier une ressource
- Delete : DELETE - Supprimer une ressource

MAP pour la structure :
- Méthode HTTP : Utilise toujours le bon verbe
- Adresse (URI) : Identifie la ressource
- Payload (JSON) : Contient les données

Phrase mnémotechnique : “CRUD ta base de données avec une MAP bien dessinée”

Question 3

Q

Quelle est la différence entre PUT et PATCH ?

Answer

A

Tableau comparatif :

Exemple PUT :

PUT /api/users/123
Body: { "name": "Alice", "email": "new@mail.com", "age": 30 }
→ Remplace TOUTES les données

Exemple PATCH :

PATCH /api/users/123
Body: { "email": "new@mail.com" }
→ Change UNIQUEMENT l'email

Règle simple : PUT = tout remplacer, PATCH = modifier un détail.

Question 4

Q

Quels sont les 5 principes REST les plus importants ?

Answer

A

Les 5 principes REST essentiels :

Architecture Client-Serveur : Séparation des responsabilités entre client et serveur
Sans État (Stateless) : Chaque requête contient toutes les informations nécessaires, le serveur ne garde pas de session
Interface Uniforme : Toutes les requêtes suivent les mêmes règles (méthodes HTTP, structure d’URL)
Système en Couches : L’API peut passer par plusieurs couches (cache, load balancer) de manière transparente
Cacheable : Les réponses doivent indiquer si elles peuvent être mises en cache

Avantage : Ces principes rendent l’API scalable, simple et universelle.

Question 5

Q

Que va retourner cette requête ?
```
POST /api/products
Body: { “name”: “Laptop”, “price”: 999 }
~~~

Answer

A

Résultat typique :
```
201 Created
Location: /api/products/42
Content-Type: application/json

{
“id”: 42,
“name”: “Laptop”,
“price”: 999,
“createdAt”: “2025-12-27T10:30:00Z”
}
```

Explication :

201 Created : Code de statut pour une création réussie
Header Location : URI de la nouvelle ressource créée
Body JSON : La ressource créée avec son ID généré et métadonnées (date de création)

Pourquoi : POST crée une nouvelle ressource, donc 201 (pas 200) et le serveur retourne l’objet complet avec l’ID.

Question 6

Q

Quels sont les codes de statut HTTP les plus courants ?

Answer

A

Codes de statut HTTP essentiels :

2xx - Succès
- 200 OK : Requête réussie (GET, PUT, PATCH)
- 201 Created : Ressource créée avec succès (POST)
- 204 No Content : Succès sans contenu à retourner (DELETE)

4xx - Erreur Client
- 400 Bad Request : Requête mal formée ou validation échouée
- 401 Unauthorized : Authentification requise
- 403 Forbidden : Accès refusé (authentifié mais pas autorisé)
- 404 Not Found : Ressource introuvable

5xx - Erreur Serveur
- 500 Internal Server Error : Erreur interne du serveur
- 503 Service Unavailable : Service temporairement indisponible

Règle : 2xx = succès, 4xx = c’est ta faute, 5xx = c’est la faute du serveur.

Question 7

Q

Quel est le problème avec ce code ?
```
GET /api/deleteUser/123
GET /api/updateProduct?id=5&price=99
~~~

Answer

A

Problème : Utilisation de GET pour des opérations qui modifient des données.

Pourquoi c’est grave :
- GET est censé être “sûr” (sans effet de bord)
- Les crawlers, caches et préchargements peuvent appeler ces URL involontairement
- Violation des principes REST

❌ Mauvais :

GET /api/deleteUser/123
GET /api/updateProduct?id=5&price=99

✅ Correct :
```
DELETE /api/users/123

PATCH /api/products/5
Body: { “price”: 99 }
```

Règle d’or : GET = lecture UNIQUEMENT. Utilisez POST/PUT/PATCH/DELETE pour les modifications.

Question 8

Q

Comment créer une route RESTful pour récupérer les commandes d’un utilisateur spécifique ?

Answer

A

GET /api/users/123/orders

Structure complète :
```
// Toutes les commandes de l’utilisateur 123
GET /api/users/123/orders
→ 200 OK
[
{ “id”: 1, “total”: 99.99, “status”: “shipped” },
{ “id”: 2, “total”: 149.99, “status”: “pending” }
]

// Une commande spécifique
GET /api/users/123/orders/1
→ 200 OK
{ “id”: 1, “userId”: 123, “total”: 99.99, “items”: […] }
```

Points clés :
- URI imbriquée montre la relation (les commandes appartiennent à l’utilisateur)
- Noms au pluriel : /users/, /orders/
- ID dans l’URL : /123/, /1/

Alternative : GET /api/orders?userId=123 (filtrage par query parameter)

Question 9

Q

Quelle méthode HTTP est idempotente et laquelle ne l’est pas ?

Answer

A

Idempotent = Peut être appelé plusieurs fois avec le même résultat

Méthodes idempotentes :
- GET : Lire plusieurs fois = même résultat
- PUT : Remplacer 5 fois = même état final
- DELETE : Supprimer 5 fois = ressource toujours supprimée
- PATCH : Généralement idempotent (selon implémentation)

Méthode NON idempotente :
- POST : Créer 5 fois = 5 ressources différentes créées

Exemple POST (non-idempotent) :
```
POST /api/users
Body: { “name”: “Alice” }

Appel 1 → Crée user ID 1
Appel 2 → Crée user ID 2
Appel 3 → Crée user ID 3
```

Exemple PUT (idempotent) :
```
PUT /api/users/123
Body: { “name”: “Alice” }

Appel 1 → User 123 = Alice
Appel 2 → User 123 = Alice (même résultat)
~~~

Question 10

Q

Comment implémenter la pagination dans une API REST ?

Answer

A

Implémentation avec query parameters :

GET /api/products?page=2&limit=20

Réponse typique :

{
  "data": [
    { "id": 21, "name": "Product 21" },
    { "id": 22, "name": "Product 22" },
    ...
  ],
  "pagination": {
    "currentPage": 2,
    "totalPages": 10,
    "totalItems": 200,
    "itemsPerPage": 20,
    "hasNext": true,
    "hasPrevious": true
  }
}

Points clés :
- page : Numéro de page (commence à 1)
- limit : Nombre d’éléments par page
- Métadonnées de pagination dans la réponse
- Liens de navigation optionnels (next, previous)

Pourquoi : Évite de surcharger le serveur et le client avec trop de données.

Question 11

Q

Quelle est la différence entre ces deux URI ?
```
/api/getUserById/123
/api/users/123
~~~

Answer

A

Tableau comparatif :

Pourquoi /api/users/123 est meilleur :

Le verbe est dans la méthode HTTP : GET indique déjà l’action
URI = ressource (nom) : /users/123 identifie “l’utilisateur 123”

Cohérence : Fonctionne avec toutes les méthodes

GET /api/users/123    ← Récupérer
PUT /api/users/123    ← Modifier
DELETE /api/users/123 ← Supprimer

Règle REST : Les URI contiennent des noms (ressources), les méthodes HTTP contiennent des verbes (actions).

Question 12

Q

Quel est le problème avec cette réponse d’erreur ?
```
GET /api/users/999
→ 200 OK
{ “success”: false, “error”: “User not found” }
~~~

Answer

A

Problème : Code de statut 200 OK alors qu’il y a une erreur.

Pourquoi c’est mauvais :
- Le client ne peut pas détecter l’erreur en vérifiant juste le code HTTP
- Les outils (Axios, fetch) ne déclencheront pas de catch/error
- Viole les standards HTTP

❌ Mauvais :

GET /api/users/999
→ 200 OK
{ "success": false, "error": "User not found" }

✅ Correct :

GET /api/users/999
→ 404 Not Found
{
  "error": {
    "code": "USER_NOT_FOUND",
    "message": "User with ID 999 not found"
  }
}

Avantage : Le code HTTP indique immédiatement le type de réponse (succès ou erreur), sans parser le JSON.

Question 13

Q

Comment filtrer et trier les résultats dans une API REST ?

Answer

A

Utilisation des query parameters :

```
// Filtrage simple
GET /api/products?category=electronics

// Filtrage multiple
GET /api/products?category=electronics&minPrice=100&maxPrice=500

// Tri
GET /api/products?sort=price&order=asc

// Recherche
GET /api/products?search=laptop

// Combinaison complète
GET /api/products?category=electronics&sort=price&order=desc&page=1&limit=20
```

Réponse :

{
  "data": [
    { "id": 1, "name": "Laptop Pro", "price": 1299, "category": "electronics" }
  ],
  "filters": {
    "category": "electronics",
    "sort": "price",
    "order": "desc"
  },
  "pagination": { ... }
}

Points clés :
- Filtres : ?key=value
- Tri : ?sort=field&order=asc|desc
- Recherche : ?search=term
- Tout via GET avec query parameters

Question 14

Q

Pourquoi versionner une API et comment faire ?

Answer

A

Pourquoi versionner :
- Faire évoluer l’API sans casser les clients existants
- Déprécier progressivement les anciennes versions
- Permettre aux clients de migrer à leur rythme

Méthode 1 : Version dans l’URL (recommandé)

GET /api/v1/users
GET /api/v2/users

Méthode 2 : Version dans le header

GET /api/users
Accept: application/vnd.api.v1+json

Méthode 3 : Version dans le query parameter

GET /api/users?version=1

Exemple concret :
```
// Version 1 (ancienne structure)
GET /api/v1/users
→ { “users”: […] }

// Version 2 (nouvelle structure)
GET /api/v2/users
→ { “data”: […], “meta”: {…} }

// Les deux coexistent !
```

Best practice : Version dans l’URL (/v1/, /v2/) car c’est le plus visible et explicite.

Question 15

Q

Comment gérer l’authentification dans une API RESTful ?

Answer

A

Méthode standard : Header Authorization avec Bearer Token

```
// 1. Login pour obtenir un token
POST /api/auth/login
Body: { “email”: “user@mail.com”, “password”: “…” }
→ 200 OK
{
“token”: “eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…”,
“expiresIn”: 3600
}

// 2. Utiliser le token dans les requêtes
GET /api/users/me
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…
→ 200 OK

// 3. Sans token = 401
GET /api/users/me
→ 401 Unauthorized
{
“error”: {
“code”: “UNAUTHORIZED”,
“message”: “Authentication required”
}
}

// 4. Token invalide/expiré = 401
GET /api/users/me
Authorization: Bearer invalid_token
→ 401 Unauthorized
```

Points clés :
- Stateless : Le token contient toutes les infos (JWT)
- Chaque requête inclut le token
- 401 si pas authentifié, 403 si pas autorisé

API Restful Flashcards

(15 cards)