Questions et réponses d'entretien sur l'API REST (Guide 2026)

Les API REST sont à la base de la plupart des intégrations sur Internet. Que vous postuliez pour un poste dans le domaine du backend, du full stack ou de l'ingénierie logicielle, vous serez probablement confronté à des questions sur la conception d'API REST, les méthodes HTTP et les modèles d'authentification.

Dans ce guide, je vais vous présenter les questions que les recruteurs posent réellement. Je les ai classées par niveau de difficulté et par type de poste, afin que vous puissiez vous concentrer sur ce qui importe le plus pour le poste que vous visez. Chaque réponse comprend des exemples pratiques et, le cas échéant, des extraits de code que vous pouvez adapter.

Il est important de garder à l'esprit que les examinateurs évaluent les connaissances fondamentales bien plus souvent que les sujets avancés. Si vous maîtrisez les bases (méthodes HTTP, codes d'état, absence d'état), vous serez en mesure de répondre avec assurance à la plupart des questions relatives aux API REST lors d'un entretien. Les motifs architecturaux sophistiqués apparaissent plus tard.

Questions d'entretien sur les API REST de base

Ces questions évaluent vos connaissances fondamentales. Attendez-vous à ce qu'elles soient abordées dans presque tous les entretiens, quel que soit le niveau hiérarchique.

1. Qu'est-ce que REST et quelles sont ses contraintes ?

REST signifie « Representational State Transfer » (transfert d'état représentatif). Il s'agit d'un style architectural pour la conception d'applications en réseau, défini par Roy Fielding dans sa thèse de doctorat en 2000.

REST comporte six contraintes :

1. Client-serveur : Séparation des préoccupations entre l'interface utilisateur et le stockage des données
2. s sur les apatrides: Chaque demande contient toutes les informations nécessaires à son traitement.
3. Mémorisable : Les réponses doivent indiquer si elles peuvent être mises en cache.
4. s du système multicouche: Les composants ne peuvent pas voir au-delà de leur couche immédiate.
5. Interface uniforme : Méthode standardisée pour interagir avec les ressources
6. Code sur demande (facultatif) : Les serveurs peuvent transmettre du code exécutable aux clients.

2. Quelle est la différence entre REST et SOAP ?

REST est un style architectural ; SOAP est un protocole. REST utilise généralement JSON sur HTTP et exploite les méthodes HTTP standard. SOAP utilise exclusivement le langage XML et définit son propre format de messagerie avec des enveloppes et des adresses.

SOAP restepertinent pour les systèmes d'entreprise nécessitant des contrats formels (WSDL) ou une sécurité au niveau des messages (WS-Security).

3. Que sont les méthodes HTTP et dans quels cas les utilise-t-on ?

Les méthodes HTTP définissent l'action à effectuer sur une ressource.

4. Quelle est la différence entre PUT et POST ?

POST crée une nouvelle ressource dont l'URI est déterminée par le serveur. PUT remplace une ressource à une URI spécifique indiquée par le client.

POST /users          → Server creates user, returns /users/123
PUT /users/123       → Client specifies URI, replaces entire resource

Si vous effectuez une opération PUT sur une URI qui n'existe pas, le serveur peut la créer. Si vous effectuez une opération PUT sur une URI existante, vous remplacez l'intégralité de la ressource.

5. Quelle est la différence entre PUT et PATCH ?

PUT remplace l'intégralité de la ressource. PATCH applique des modifications partielles.

# PUT replaces everything
PUT /users/123
{"name": "Khalid", "email": "khalid@example.com", "role": "admin"}

# PATCH updates only specified fields
PATCH /users/123
{"role": "admin"}

6. Que signifie « sans état » dans REST ?

« Stateless » signifie que chaque requête doit contenir toutes les informations dont le serveur a besoin pour la traiter. Le serveur ne stocke aucun contexte client entre les requêtes.

Cela signifie qu'il n'y a pas de sessions côté serveur. Si un utilisateur est authentifié, le client doit envoyer des informations d'identification (généralement un jeton) avec chaque requête.

7. Qu'est-ce qui caractérise une API RESTful ?

Une API est véritablement RESTful lorsqu'elle satisfait à toutes les contraintes REST, y compris HATEOAS (Hypermedia as the Engine of Application State). Dans la pratique, la plupart des API qui se qualifient de « REST » sont en réalité « de type REST » ou correspondent au niveau 2 du modèle de maturité de Richardson. Et honnêtement, cela convient parfaitement à la plupart des cas d'utilisation.

Niveaux du modèle de maturité de Richardson pour les API REST. Image fournie par l'auteur.

8. Quels sont les codes d'état HTTP de base qu'il est important de connaître ?

Il est important de connaître au moins ces sept codes d'état essentiels qui couvrent la majorité des scénarios API :

9. Quelle est la différence entre une ressource et un point de terminaison ?

Une ressource est une entité de données (utilisateur, commande, produit). Un point de terminaison est le chemin d'accès URL qui permet d'accéder à cette ressource.

Resource: User
Endpoints: GET /users, GET /users/123, POST /users

10. Quelles sont les meilleures pratiques en matière de conception d'URI ?

Veuillez utiliser des noms, et non des verbes. Veuillez utiliser des minuscules et des tirets pour les noms composés de plusieurs mots dans les URI. Veuillez utiliser des noms pluriels pour les collections.

Good:  /users, /users/123, /order-items
Bad:   /getUsers, /Users, /order_items

Veuillez éviter les imbrications profondes. Au lieu de /users/123/posts/456/comments/789, veuillez envisager /comments/789 ou /comments?post_id=456.

11. Qu'est-ce que l'idempotence et quelles méthodes HTTP sont idempotentes ?

Une opération est idempotente si l'effectuer plusieurs fois produitle même résultat que de l'effectuer une seule fois.

Un PATCH qui définit une valeur estidempotent ; un PATCH qui incrémente un compteur ne l'est pas.

12. Quelle est la différence entre les méthodes sûres et les méthodes idempotentes ?

Les méthodes sécurisées ne modifient pas les ressources (GET, HEAD, OPTIONS). Les méthodes idempotentes peuvent être appelées plusieurs fois avec le même effet (GET, PUT, DELETE).

Toutes les méthodes sécurisées sont idempotentes, mais toutes les méthodes idempotentes ne sont pas sécurisées. DELETE est idempotent mais n'est pas sécurisé car il modifie l'état.

13. Quand est-il préférable d'utiliser des paramètres de requête plutôt que des paramètres de chemin ?

Les paramètres de chemin identifient une ressource spécifique. Les paramètres de requête permettent de filtrer, trier ou paginer les collections.

Path:   /users/123              (specific user)
Query:  /users?status=active    (filtered collection)
        /users?sort=name&limit=10

14. Qu'est-ce que la négociation de contenu ?

La négociation de contenu permet aux clients de demander différentes représentations d'une ressource. Le client envoie un en-tête « Accept » et le serveur répond avec le format approprié.

Accept: application/json    → Server returns JSON
Accept: application/xml     → Server returns XML

15. Quel est l'objectif de la méthode OPTIONS ?

OPTIONS renvoie les méthodes HTTP prises en charge par un serveur pour une URL spécifique. Les navigateurs l'utilisent pour les requêtes CORS pré-vol afin de vérifier si les requêtes inter-origines sont autorisées.

Questions d'entretien intermédiaires sur l'API REST

Ces questions évaluent l'application pratique et la prise de décision. Veuillez les envisager pour des postes de niveau intermédiaire.

16. Quelle est la différence entre 401 et 403 ?

Il s'agit des deux codes d'état les plus fréquemment confondus. J'ai observé des ingénieurs expérimentés confondre ces concepts lors de revues de code.

401 Non autorisé

Signifie non authentifié. Le serveur ne reconnaît pas votre identité. Votre réponse devrait inviter l'utilisateur à se connecter.

403 Accès refusé

Signifie non autorisé. Le serveur reconnaît votre identité, mais vous ne disposez pas des autorisations nécessaires. Une nouvelle authentification ne sera pas utile.

Organigramme illustrant la distinction entre l'authentification et l'autorisation. Image fournie par l'auteur.

17. Quelle est la différence entre 400 et 422 ?

Voici quelques exemples illustrant la différence :

400 Demande incorrecte

Cela indique une syntaxe incorrecte. Le serveur n'est pas en mesure d'analyser la requête (structure JSON non valide, en-têtes obligatoires manquants).

422 Entité non traitée

Cela indique une syntaxe valide mais des erreurs sémantiques. Le JSON est valide, mais les données ne passent pas la validation (format d'adresse e-mail non valide, mot de passe trop court).

# 400: Cannot parse
{"name": "Khalid",}  # Trailing comma breaks JSON

# 422: Valid JSON, invalid data
{"email": "not-an-email"}  # Fails validation

18. Quand est-il approprié d'utiliser le code 409 Conflict ?

Utilisez 409 lorsque la requête est en conflit avec l'état actuel de la ressource :

• Échecs de verrouillage optimiste (incompatibilité ETag)
• Violations de contraintes uniques (nom d'utilisateur en double)
• Transitions d'état non valides (annulation d'une commande déjà expédiée)

19. Comment mettez-vous en œuvre la pagination ?

Deux approches principales :

Pagination basée sur le décalage

Simple, mais présente des problèmes de performance avec les ensembles de données volumineux.

GET /users?limit=20&offset=40

Pagination à l'aide du curseur

Évolue mieux et évite la « dérive des pages » lorsque les données changent.

GET /users?limit=20&cursor=eyJpZCI6MTIzfQ

Des entreprises telles que Stripe, GitHub et Slack utilisent la pagination par curseur pour les grands ensembles de données.

20. Quelles sont les stratégies courantes de gestion des versions d'API ?

Il existe trois approches principales, chacune présentant des avantages et des inconvénients différents :

Gestion des versions URI

C'est le cas le plus fréquent. Il est explicite et facile à déboguer.

GET /v1/users
GET /v2/users

Versionnement des en-têtes

URL plus claires, mais plus difficiles à tester dans les navigateurs.

GET /users
Accept-Version: v2

Gestion des versions des paramètres de requête

Facile à ajouter, mais encombre les URL.

GET /users?version=2

21. Qu'est-ce qu'un ETag et comment fonctionne la mise en cache ?

Un ETag est un identifiant de version pour une ressource. Le serveur l'envoie dans ses réponses ; le client le renvoie dans les requêtes suivantes afin de vérifier si la ressource a changé.

# First request
GET /users/123
Response: ETag: "abc123"

# Subsequent request
GET /users/123
If-None-Match: "abc123"
Response: 304 Not Modified (if unchanged)

22. Quelles méthodes d'authentification sont utilisées pour les API REST ?

Les quatre méthodes d'authentification les plus courantes sont les clés API, les jetons porteurs, OAuth 2.0 et JWT :

23. Qu'est-ce que le JWT et comment fonctionne-t-il ?

Le JWT (JSON Web Token) se compose de trois parties : En-tête, charge utile et signature. Veuillez vous renseigner sur l'utilisation de JSON dans Python.

Header: {"alg": "RS256", "typ": "JWT"}
Payload: {"sub": "user123", "exp": 1704153600}
Signature: RSASHA256(base64(header) + "." + base64(payload), privateKey)

Le serveur signe le jeton ; les clients l'envoient avec leurs requêtes. Le serveur valide la signature sans effectuer de recherche dans la base de données.

24. Quelle est la différence entre RS256 et HS256 ?

HS256 (symétrique) : Même secret signe et vérifie. Risque si plusieurs services doivent vérifier les jetons.

RS256 (asymétrique) : La clé privée signe, la clé publique vérifie. Recommandé pour les systèmes distribués où plusieurs services valident les jetons.

25. Qu'est-ce que HATEOAS ?

HATEOAS (Hypermedia as the Engine of Application State) signifie que les réponses incluent des liens vers des actions et des ressources connexes.

{
  "id": 123,
  "name": "Khalid",
  "links": [
    {"rel": "self", "href": "/users/123"},
    {"rel": "orders", "href": "/users/123/orders"}
  ]
}

Dans la pratique, la plupart des API n'implémentent pas HATEOAS dans son intégralité. Comprenez le concept, mais ne vous attendez pas à le mettre en œuvre dans la plupart des emplois. Même les grandes entreprises technologiques développent rarement des API entièrement conformes à HATEOAS.

26. Comment gérez-vous les erreurs de manière cohérente ?

Veuillez utiliser le format RFC 7807 Problem Details pour des réponses d'erreur cohérentes :

{
  "type": "https://api.example.com/errors/validation",
  "title": "Validation Error",
  "status": 422,
  "detail": "Email format is invalid",
  "instance": "/users"
}

27. Qu'est-ce que la limitation de débit et pourquoi est-elle importante ?

La limitation du débit protège votre API contre les abus et garantit une utilisation équitable. Réponse courante :

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0

28. Comment concevez-vous le filtrage et le tri ?

Veuillez utiliser des paramètres de requête avec des conventions claires :

# Filtering
GET /products?category=electronics&price[gte]=100&price[lte]=500

# Sorting (prefix - for descending)
GET /users?sort=-created_at,name

Questions d'entretien avancées sur l'API REST

Ces questions évaluent la réflexion architecturale. Veuillez les envisager pour des postes de haut niveau.

29. Quels sont les changements entre OAuth 2.0 et OAuth 2.1 ?

OAuth 2.1 consolide les meilleures pratiques en matière de sécurité :

Point essentiel à retenir : veuillez utiliser le flux de code d'autorisation avec PKCE pour tous les types de clients.

30. Comment mettez-vous en œuvre l'idempotence pour les points de terminaison de paiement ?

Veuillez utiliser des clés idempotentes pour sécuriser les requêtes POST en cas de nouvelles tentatives :

async def handle_payment(request: Request, payment: PaymentCreate):
    idempotency_key = request.headers.get("Idempotency-Key")
    
    # Check if already processed
    cached = await redis.get(f"idem:{idempotency_key}")
    if cached:
        return JSONResponse(json.loads(cached))
    
    # Process payment
    result = await process_payment(payment)
    
    # Cache result (24-hour TTL)
    await redis.setex(f"idem:{idempotency_key}", 86400, json.dumps(result))
    return result

Le client génère un UUID et l'envoie avec la requête. Si la même clé est à nouveau reçue, renvoyez la réponse mise en cache.

31. Comment concevriez-vous un limiteur de débit distribué ?

Pour les systèmes distribués, il n'est pas possible d'utiliser des compteurs en mémoire, car le trafic est réparti entre les instances. Il s'agit d'un piège courant qui pose des difficultés aux candidats.

Architecture :

1. Utiliser Redis pour le stockage centralisé des compteurs
2. Mettre en œuvre l'algorithme Token Bucket pour la tolérance aux rafales.
3. Utilisez des opérations atomiques (scripts Lua) pour éviter les conditions de concurrence.

# Pseudocode for Token Bucket
tokens = redis.get(user_id) or max_tokens
if tokens > 0:
    redis.decr(user_id)
    process_request()
else:
    return 429

32. Dans quels cas préférez-vous utiliser gRPC plutôt que REST ?

Optez pour gRPC dans les cas suivants :

• Communication interne entre microservices (amélioration du débit de 5 à 10 fois)
• Exigences en matière de streaming en temps réel
• Mobile vers backend avec contraintes de bande passante
• Environnements polyglottes nécessitant des contrats stricts

Veuillez choisir REST pour :

• API publiques avec divers utilisateurs
• Applications Web (prise en charge universelle par les navigateurs)
• Opérations CRUD simples
• Équipes peu familières avec les Protocol Buffers

33. Comment gérez-vous les opérations de longue durée ?

Veuillez utiliser le modèle de requête asynchrone :

1. Le client envoie une demande

2. Le serveur renvoie 202 Accepted avec une URL d'état.

3. Le client interroge l'URL d'état jusqu'à ce que l'opération soit terminée.

POST /reports
Response: 202 Accepted
Location: /reports/abc123/status

GET /reports/abc123/status
Response: {"status": "processing", "progress": 45}

GET /reports/abc123/status
Response: {"status": "completed", "result_url": "/reports/abc123"}

34. Qu'est-ce que le modèle Saga ?

Saga gère les transactions distribuées entre les microservices sans verrouillage. Chaque service exécute une transaction locale et publie un événement. Si une étape échoue, les transactions compensatoires annulent les étapes précédentes.

Order Created → Payment Processed → Inventory Reserved → Order Confirmed
                     ↓ (failure)
              Release Payment → Cancel Order

35. Quelles sont les vulnérabilités de sécurité courantes liées aux JWT ?

Confusion algorithmique L'attaquant remplace RS256 par HS256 et signe avec la clé publique. Correction : veuillez toujours ajouter les algorithmes à la liste blanche.

# Vulnerable
jwt.decode(token, key)

# Secure
jwt.decode(token, key, algorithms=["RS256"])

Algorithme « none » : L'attaquant supprime complètement la signature. Correction : rejeter l'algorithme « none ».

Questions relatives à l'API REST pour les développeurs backend

36. Qu'est-ce que le problème de requête N+1 ?

Le problème N+1 survient lorsque vous récupérez N enregistrements, puis exécutez une requête distincte pour chaque relation d'enregistrement.

# N+1 Problem: 101 queries for 100 users
users = User.query.all()  # 1 query
for user in users:
    print(user.posts)     # 100 queries

Solutions :

Django : Veuillez utiliser select_related() pour les clés étrangères et prefetch_related() pour les relations plusieurs-à-plusieurs.

# 2 queries instead of 101
users = User.objects.prefetch_related('posts').all()

SQLAlchemy : Veuillez utiliser joinedload() ou selectinload().

37. Comment configurez-vous le regroupement de connexions ?

Le regroupement de connexions réutilise les connexions à la base de données au lieu d'en créer de nouvelles pour chaque requête.

# SQLAlchemy
engine = create_engine(
    "postgresql://user:pass@host/db",
    pool_size=5,           # Permanent connections
    max_overflow=10,       # Temporary overflow
    pool_timeout=30,       # Wait timeout
    pool_pre_ping=True     # Validate before use
)

38. Quelles stratégies de mise en cache connaissez-vous ?

Il existe trois stratégies principales de mise en cache, chacune étant optimisée pour différents modèles d'accès :

39. Comment mettez-vous en œuvre la vérification de signature webhook ?

import hmac
import hashlib

def verify_webhook(payload: bytes, signature: str, secret: str) -> bool:
    expected = 'sha256=' + hmac.new(
        secret.encode(),
        payload,
        hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, signature)

40. Quels indicateurs permettent d'évaluer la santé d'une API ?

Il est recommandé de surveiller ces quatre indicateurs clés pour évaluer la santé de votre API :

Questions sur l'API REST pour les développeurs Full Stack

41. À quel moment un navigateur envoie-t-il une requête CORS pré-vol ?

Les navigateurs envoient une requête OPTIONS préalable pour :

• Méthodes autres que GET, HEAD, POST
• En-têtes personnalisés (Autorisation, X-API-Key)
• Type de contenu autre que form-urlencoded, multipart/form-data, text/plain

42. Comment configurer CORS de manière sécurisée ?

// Express.js
app.use(cors({
  origin: ['https://yourdomain.com'],  // Never use * with credentials
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization']
}));

Veuillez ne jamais utiliser de caractères génériques (*) avec les informations d'identification. Veuillez ne jamais autoriser l'origine null.

43. Où devriez-vous stocker les jetons sur le client ?

Le stockage des jetons implique des compromis en matière de sécurité entre les vulnérabilités XSS et CSRF.

Meilleures pratiques : Veuillez stockerles jetons d'actualisationdans des cookies HttpOnly à l'aide de l'SameSite=Strict. Veuillez conserver les jetons d'accès en mémoire.

44. Quand est-il préférable d'utiliser les WebSockets plutôt que le SSE ?

Le choix dépend de la nécessité d'une communication bidirectionnelle et de la manière dont vous souhaitez gérer la reconnexion :

Veuillez utiliser SSE pour les notifications, les flux en direct et les cotations boursières. Veuillez utiliser les WebSockets pour le chat, les jeux multijoueurs et l'édition collaborative.

45. Comment gérez-vous les téléchargements de fichiers ?

Pour les fichiers volumineux, veuillez utiliser les téléchargements par morceaux avec suivi de la progression :

async function chunkedUpload(file, chunkSize = 5 * 1024 * 1024) {
  const totalChunks = Math.ceil(file.size / chunkSize);
  
  for (let i = 0; i < totalChunks; i++) {
    const chunk = file.slice(i * chunkSize, (i + 1) * chunkSize);
    await uploadChunk(uploadId, i, chunk);
  }
}

Questions sur l'API REST basées sur des scénarios

46. Concevez une API REST pour un système de réservation hôtelière.

Ressources :

• /hotels - Liste et recherche d'hôtels

• /hotels/{id}/rooms - Chambres disponibles

• /bookings - Créer et gérer les réservations

• /guests/{id} - Profils des invités

Décisions importantes :

• Veuillez utiliser la pagination par curseur pour la recherche d'hôtels.
• Mettre en œuvre un verrouillage optimiste pour la disponibilité des salles
• Renvoyer une erreur 409 en cas de tentative de double réservation.
• Veuillez utiliser des clés idempotentes pour le traitement des paiements.

47. Comment mettriez-vous en œuvre les suppressions temporaires ?

Veuillez ajouter un deleted_at horodatage au lieu de supprimer des enregistrements :

@app.delete("/users/{user_id}")
def delete_user(user_id: int):
    user = db.get(user_id)
    user.deleted_at = datetime.utcnow()
    db.commit()
    return Response(status_code=204)

@app.get("/users")
def list_users(include_deleted: bool = False):
    query = User.query
    if not include_deleted:
        query = query.filter(User.deleted_at.is_(None))
    return query.all()

48. Comment procéder à la migration de la version 1 vers la version 2 sans perturber les clients ?

Veuillez utiliser le modèle Strangler Fig :

1. Déployer la version 2 parallèlement à la version 1
2. Transférer les nouvelles fonctionnalités vers la version 2
3. Veuillez procéder à la migration progressive des terminaux existants.
4. Communiquer la dépréciation via l'en-tête Sunset
5. Veuillez supprimer la version 1 après la période de migration.

49. Comment concevriez-vous une API de recherche avec un filtrage complexe ?

Pour une recherche de produit avec plusieurs filtres :

GET /products?q=laptop&category=electronics&price[gte]=500&price[lte]=2000&brand=apple,dell&in_stock=true&sort=-rating&limit=20&cursor=abc123

Décisions relatives à la conception :

• Veuillez utiliser Elasticsearch pour la recherche en texte intégral (les bases de données relationnelles rencontrent des difficultés avec la correspondance approximative).
• Mettre en œuvre la recherche à facettes pour afficher les options de filtrage disponibles.
• Le nombre de résultats renvoyés par chaque filtre est affiché afin que les utilisateurs puissent évaluer le nombre de résultats générés par chaque filtre.
• Mémoriser les combinaisons de recherche fréquentes

50. Comment gérez-vous la gestion des versions API dans une architecture microservices ?

Options :

1. Gestion des versions au niveau de la passerelle: La passerelle API achemine /v1/* vers les anciens services et /v2/* vers les nouveaux.

2. Gestion des versions au niveau du service : Chaque service gère sa propre négociation de version.

3. Contrats axés sur le consommateur : Veuillez utiliser Pact ou des outils similaires pour garantir la compatibilité.

Pour la plupart des équipes, la gestion des versions au niveau de la passerelle offre la séparation la plus claire.

51. Comment mettriez-vous en œuvre la limitation du débit pour différents niveaux d'utilisateurs ?

La solution consiste à définir des limites spécifiques à chaque niveau et à les vérifier à l'aide des compteurs Redis :

RATE_LIMITS = {
    "free": {"requests": 100, "window": 3600},
    "pro": {"requests": 1000, "window": 3600},
    "enterprise": {"requests": 10000, "window": 3600}
}

async def rate_limit_middleware(request: Request):
    user = get_current_user(request)
    tier = user.subscription_tier
    limits = RATE_LIMITS[tier]
    
    key = f"rate:{user.id}:{current_hour()}"
    count = await redis.incr(key)
    
    if count == 1:
        await redis.expire(key, limits["window"])
    
    if count > limits["requests"]:
        raise HTTPException(
            status_code=429,
            headers={
                "X-RateLimit-Limit": str(limits["requests"]),
                "X-RateLimit-Remaining": "0",
                "Retry-After": str(seconds_until_reset())
            }
        )

Questions relatives à l'API REST comportementale

52. Expliquer REST à une personne non initiée à la technologie

Considérez une API REST comme un serveur dans un restaurant. Il n'est pas possible pour vous (le client) d'accéder directement à la cuisine. Au lieu de cela, vous indiquez au serveur ce que vous souhaitez commander sur le menu, et il vous l'apporte. Le menu est similaire à la documentation de l'API, il répertorie les options disponibles. Le serveur suit des règles spécifiques : vous demandez quelque chose (GET), vous commandez quelque chose de nouveau (POST) ou vous renvoyez quelque chose (DELETE). Si la cuisine est à court d'un produit, le serveur vous en informe (404 Not Found) afin que vous n'attendiez pas indéfiniment.

Cette analogie s'applique remarquablement bien aux réunions avec les parties prenantes.

53. Veuillez décrire une occasion où vous avez optimisé une API.

Veuillez utiliser la méthode STAR :

• Situation: Notre API de recherche affichait des temps de réponse de 3 secondes pendant les pics de trafic.
• Tâche: « Il était nécessaire de réduire la latence sans apporter de modifications majeures à l'architecture. »
• Action: J'ai intégré la mise en cache Redis pour les requêtes fréquentes, implémenté la pagination basée sur le curseur et ajouté des index de base de données.
• Résultat: Le temps de réponse a été réduit à 200 ms et nous avons traité cinq fois plus de trafic.

54. Comment communiquez-vous les modifications importantes aux utilisateurs de l'API ?

1. Veuillez annoncer à l'avance: Veuillez nous informer au moins 6 à 12 mois à l'avance de tout changement important.

2. Veuillez utiliser l'en-tête Sunset: Sunset: Sat, 31 Dec 2026 23:59:59 GMT

3. Fournir des guides de migration : Veuillez documenter précisément les changements et la manière de s'y adapter.

4. Veuillez exécuter les deux versions : Continuer à utiliser l'ancienne version pendant la transition

5. Surveiller l'utilisation : Veuillez identifier les clients qui utilisent encore l'ancienne version.

55. Quelle documentation établissez-vous pour les API ?

Les documents essentiels comprennent :

• Spécification OpenAPI/Swagger : Contrat lisible par machine
• Guide de démarrage : Premier appel API en moins de 5 minutes
• Guide d'authentification : Comment obtenir et utiliser les identifiants
• Référence d'erreur : Tous les codes d'erreur possibles et la manière de les traiter
• Journal des modifications : Quels sont les changements apportés à chaque version ?
• Documentation relative à la limite de débit : Limites par niveau et gestion des erreurs 429

56. Dans quels cas ne recommanderiez-vous pas l'utilisation de REST ?

REST n'est pas toujours le choix le plus approprié. Savoir quand utiliser des alternatives à l' témoigne d'une grande maturité architecturale. J'ai observé des équipes imposer l'utilisation de REST dans des cas où cela engendre plus de problèmes que cela n'en résout.

Référence rapide de l'API REST

Veuillez utiliser cette section comme référence rapide lorsque vous avez besoin de vérifier les propriétés des méthodes HTTP, les codes d'état ou les modèles courants lors de la préparation d'un entretien ou d'un développement en situation réelle.

Comparaison des méthodes HTTP

Ce tableau résume les principales propriétés de chaque méthode HTTP,vous aidant ainsi àchoisir celle qui convient le mieux à votre cas d'utilisation.

Référence des codes d'état

Voici les codes d'état HTTP les plus couramment utilisés, classés par catégorie. Concentrez-vous sur la compréhension de l'utilisation de chacun plutôt que sur la mémorisation de l'ensemble des spécifications.

2xx Réussite

• 200 OK: GET, PUT, PATCH réussis
• 201 Créé le : POST réussi (inclure l'en-tête Location)
• 204 Aucun contenu: Suppression réussie

Erreurs client 4xx

• 400 Demande incorrecte: Syntaxe incorrecte
• 401 Non autorisé: Veuillez vous identifier
• 403 Accès refusé: Authentifié mais non autorisé
• 404 Page introuvable: La ressource n'existe pas
• 409 Conflit: Conflit d'État
• 422 Entité non traitée: Erreur de validation
• 429 Demandes excessives: Taux limité

Erreurs 5xx du serveur

• Erreur interne du serveur 500: Défaillance générale du serveur
• 502 Bad Gateway: Erreur du serveur en amont
• 503 Service indisponible: Surcharge temporaire

Erreurs courantes à éviter

Même les développeurs expérimentés peuvent se trouver confrontés à ces difficultés. Veuillez prêter attention aux pièges courants suivants lors de la conception ou de la mise en œuvre d'API REST :

• Utilisation de verbes dans les URL (par exemple, /getUsers au lieu de /users)

• Renvoyer 200 OK pour les états d'erreur, ce qui perturbe la gestion des erreurs côté client

• Confusion entre les codes d'erreur 401 et 403 (authentification vs. Autorisation)

• URL imbriquées au-delà de deux niveaux

• Stockage des jetons dans localStorage (crée des vulnérabilités XSS)

• Ignorer l'idempotence pour les requêtes POST

• Renvoi de messages d'erreur génériques sans détails exploitables

Conclusion

Je reconnais que mémoriser des définitions ne garantit pas la réussite à tous les entretiens techniques. En réalité, l'ingénierie dans le monde réel nécessite souvent de déroger aux règles « strictes » dont nous venons de discuter, et les examinateurs s'intéressent davantage à votre raisonnement qu'à votre capacité à réciter les spécifications RFC. Pour les postes hautement spécialisés, une connaissance approfondie du domaine ou une expertise spécifique dans un cadre particulier peut encore être le facteur déterminant.

Cependant, il est important de maîtriser ces principes fondamentaux REST, même si vous ne rencontrez pas ces questions précises. Il sert de modèle pour comprendre le fonctionnement du web moderne. Lorsque vous êtes invité à concevoir un nouveau système ou à résoudre un problème de production, comprendre la différence entre un 401 et un 403 (comme expliqué précédemment) vous permet de résoudre les problèmes plus rapidement. Vous comprendrez parfaitement pourquoi la standardisation de vos interactions API, et non pas seulement l'écriture de code fonctionnel, est la marque distinctive d'un ingénieur senior.

Si vous souhaitez approfondir vos connaissances sur la création de ces systèmes, veuillez consulter notre cours Introduction aux API en Python .