Les questions sur les API REST permettent de vérifier si vous savez concevoir une interface que d'autres utiliseront sans mauvaise surprise. Voici 20 questions avec leurs réponses, des bases aux détails de conception qui reviennent en entretien backend et full-stack. Pour les règles sur les méthodes HTTP, nous avons suivi les définitions de la RFC 9110.
Les bases
1. Qu'est-ce que REST ?
REST est un style d'architecture pour les systèmes en réseau, construit autour de ressources identifiées par des URL, manipulées avec un petit ensemble d'opérations standard et décrites par des représentations comme JSON. Une API REST est sans état : chaque requête transporte ce dont le serveur a besoin pour la traiter, si bien que n'importe quel serveur peut répondre à n'importe quelle requête.
2. Qu'est-ce qui rend une API « RESTful » en pratique ?
- Des noms pour les ressources dans les URL, comme /orders/42, et non des verbes comme /getOrder
- Des méthodes HTTP standard pour les actions
- Des codes de statut porteurs de sens
- Des requêtes sans état
- Des représentations et des formats d'erreur cohérents
En entretien, précisez que peu d'API réelles respectent toutes les contraintes REST, et que vous visez un comportement prévisible.
3. À quoi servent les principales méthodes HTTP ?
| Méthode | Usage | Sûre | Idempotente |
|---|---|---|---|
| GET | Lire une ressource | Oui | Oui |
| POST | Créer une ressource ou déclencher une action | Non | Non |
| PUT | Remplacer une ressource | Non | Oui |
| PATCH | Mettre à jour partiellement une ressource | Non | Pas garantie |
| DELETE | Supprimer une ressource | Non | Oui |
« Sûre » signifie que la requête ne modifie pas l'état du serveur. « Idempotente » signifie que l'envoyer plusieurs fois a le même effet que l'envoyer une seule fois.
4. Que signifie idempotent, et pourquoi est-ce important ?
Si une requête est répétée, l'état final est identique à celui obtenu après une seule requête. C'est important parce que les réseaux échouent. Si un client dépasse le délai d'attente sur un PUT, il peut réessayer sans crainte. Un POST qui crée une commande pourrait en créer deux, c'est pourquoi les API acceptent souvent une clé d'idempotence : le client envoie une clé unique, et le serveur renvoie le résultat stocké s'il revoit cette clé.
5. PUT ou PATCH ?
PUT remplace la ressource entière par le corps que vous envoyez, et les champs que vous omettez sont effacés ou réinitialisés. PATCH ne modifie que les champs que vous envoyez. Utilisez PATCH pour les petites mises à jour et PUT quand le client détient la représentation complète.
Codes de statut et erreurs
6. Quels codes de statut utilisez-vous, et quand ?
| Code | Usage |
|---|---|
| 200 | Succès avec un corps de réponse |
| 201 | Créé, avec un en-tête Location vers la nouvelle ressource |
| 204 | Succès sans corps, comme une suppression |
| 400 | La requête est mal formée ou invalide |
| 401 | Non authentifié |
| 403 | Authentifié mais non autorisé |
| 404 | Ressource introuvable |
| 409 | Conflit avec l'état actuel, comme un doublon |
| 422 | Bien formée mais échoue à la validation |
| 429 | Trop de requêtes |
| 500 | Erreur serveur |
| 503 | Service indisponible |
Une question de suivi fréquente porte sur la différence entre 401 et 403. 401 signifie « je ne sais pas qui vous êtes », et 403 signifie « je sais qui vous êtes, et vous ne pouvez pas faire cela ».
7. Comment une API doit-elle renvoyer les erreurs ?
Utilisez le bon code de statut et un corps cohérent. Un bon corps d'erreur contient un code stable exploitable par la machine, un message lisible par un humain et, pour les erreurs de validation, les champs qui ont échoué. Ne divulguez pas de traces de pile ni de détails internes aux clients.
8. Comment gérez-vous la validation ?
Validez côté serveur même si le client valide aussi. Renvoyez tous les problèmes en une seule fois quand c'est possible, pour que l'utilisateur ne les corrige pas un par un, et utilisez 400 ou 422 de manière cohérente.
Conception
9. Comment concevoir les URL pour les relations ?
On imbrique quand la ressource enfant n'a de sens que rattachée à la ressource parente, par exemple /users/7/orders. On garde l'imbrication peu profonde. Au-delà d'un ou deux niveaux, on expose l'enfant directement, par exemple /orders/42, et on filtre avec des paramètres de requête, par exemple /orders?userId=7.
10. Comment paginer une liste ?
| Méthode | Fonctionnement | Compromis |
|---|---|---|
| Offset et limit | ?offset=40&limit=20 | Simple, mais lent sur les grandes tables et peut sauter ou répéter des éléments quand les données changent |
| Curseur | ?after=<token>&limit=20 | Stable et rapide, mais impossible d'aller directement à la page 50 |
| Numéro de page | ?page=3 | Pratique pour les interfaces, avec les mêmes inconvénients que l'offset |
La pagination par curseur est la réponse habituelle pour des données volumineuses ou qui évoluent vite. On renvoie le curseur suivant et une indication sur la présence d'autres résultats.
11. Comment filtrer et trier ?
On utilise des paramètres de requête, par exemple ?status=open&sort=-created_at. On définit une liste blanche des champs autorisés, pour éviter d'exposer des colonnes non indexées ou sensibles et pour garder des requêtes rapides.
12. Comment versionner une API ?
| Approche | Exemple | Remarque |
|---|---|---|
| Dans l'URL | /v2/orders | Simple et visible |
| Dans un en-tête | Accept: application/vnd.example.v2+json | URL plus propres, mais plus difficile à tester dans un navigateur |
| Paramètre de requête | ?version=2 | Facile, mais facile à oublier |
Quoi qu'on choisisse, on évite les changements cassants au sein d'une même version. Ajouter des champs est généralement sans risque, en supprimer ou en renommer ne l'est pas.
13. Qu'est-ce que HATEOAS ?
Les réponses incluent des liens vers les actions associées, ce qui permet à un client de découvrir ce qu'il peut faire ensuite au lieu de coder les URL en dur. Cela fait partie de la définition de REST, mais peu d'API l'implémentent complètement. Dites que vous connaissez le principe et que la plupart des équipes utilisent plutôt une documentation et une description OpenAPI.
Sécurité et performance
14. Comment authentifier une API ?
Les choix courants sont les clés d'API pour un usage simple de serveur à serveur, les jetons porteurs comme les JSON Web Tokens, et OAuth 2.0 quand un utilisateur autorise une application à accéder à ses données. On utilise toujours HTTPS. On garde les secrets hors des URL, car les URL finissent dans les logs.
15. Quelle est la différence entre authentification et autorisation ?
L'authentification consiste à prouver qui vous êtes. L'autorisation consiste à décider ce que vous avez le droit de faire. Les échecs diffèrent : un jeton absent ou invalide donne un 401, et un jeton valide sans permission donne un 403.
16. Comment protéger une API contre les abus ?
Limitation du débit par clé ou par IP, limites de taille des requêtes, validation des entrées, délais d'attente et surveillance du trafic inhabituel. On renvoie un 429 avec un en-tête Retry-After pour indiquer aux clients quand réessayer.
17. Comment fonctionne le cache HTTP pour les API ?
Les réponses peuvent porter des en-têtes Cache-Control qui indiquent combien de temps une réponse peut être réutilisée. Un ETag identifie une version de la réponse. Le client le renvoie dans If-None-Match, et le serveur répond 304 Not Modified sans corps si rien n'a changé. Cela économise de la bande passante et de la charge.
18. Qu'est-ce que CORS ?
Les navigateurs empêchent une page web de lire les réponses d'une autre origine, sauf si le serveur l'autorise. Le serveur envoie des en-têtes comme Access-Control-Allow-Origin pour indiquer quelles origines peuvent lire ses réponses. C'est appliqué par le navigateur, pas par le serveur, donc cela ne protège pas une API des clients qui ne sont pas des navigateurs.
En pratique
19. REST, GraphQL ou gRPC ?
| Idéal pour | Coût | |
|---|---|---|
| REST | API publiques simples, cacheables et largement comprises | Sur-récupération et nombreux allers-retours pour des écrans complexes |
| GraphQL | Clients qui ont besoin de choisir précisément les champs et de combiner les données en une seule requête | Plus de complexité côté serveur et un cache plus difficile |
| gRPC | Appels internes rapides entre services avec des contrats stricts | Moins pratique pour les navigateurs et l'usage public |
La meilleure réponse cite une situation, pas un gagnant.
20. Comment documenter et tester une API ?
On la décrit avec une spécification OpenAPI, qui peut générer la documentation et le code client. On teste à trois niveaux : des tests unitaires pour la logique, des tests d'intégration contre une vraie base de données, et des tests de contrat pour détecter les changements cassants. On teste aussi les cas d'échec, comme une entrée invalide et des jetons expirés.
Comment se préparer
- Savoir concevoir une petite API au tableau, comme une liste de tâches ou un système de commandes, avec les URL, les méthodes, les codes de statut et une réponse d'erreur.
- Maîtriser l'idempotence et la pagination sur le bout des doigts. Ce sont les sujets qui reviennent le plus.
- Préparer une anecdote sur une API que vous avez conçue ou utilisée, et une erreur que vous éviteriez la prochaine fois.
Pour vous entraîner sur des sujets proches, consultez nos guides sur les questions d'entretien Spring Boot, les questions d'entretien Node.js, les questions d'entretien de system design et les questions d'entretien de réseaux informatiques.
Entraînez-vous à voix haute et avec vos propres mots. Une transcription par la suite montre où vous avez divagué ou manqué l'essentiel. Respectez les règles de l'employeur sur les outils d'IA lors de tout entretien ou test en direct.
Entraînez vos réponses avec YesToTheOffer
Répétez à voix haute, obtenez des réponses construites à partir de votre propre CV et consultez votre transcription par la suite. 30 minutes gratuites, sans abonnement.
