25 questions et réponses clés pour l'entretien sur l'API REST

Dans le secteur du développement logiciel , les intégrations jouent un rôle clé dans la conception des applications. L'une des principales technologies à cet effet est l' API REST . La connaissance de l'API REST est une compétence importante pour tout spécialiste technologique. Dans cet article, nous présenterons 25 questions API REST qui vous aideront à préparer un entretien d'embauche et à améliorer vos compétences. Bonne lecture!

Tout d'abord, l'intervieweur divise généralement les questions sur l'API REST en questions théoriques et pratiques. Tout d'abord, ils posent 2 à 3 questions théoriques sur la terminologie et les méthodes de requête HTTP, puis vous recevez une tâche pratique sur la rédaction d'une requête.

Cet article contient des questions théoriques fréquemment posées et je prévois de publier des exemples de tâches pratiques liées à l'API REST dans le prochain article. Nous ne savons pas à l'avance quelles questions vous recevrez lors d'un entretien, mais je suis sûr qu'en parcourant notre liste de questions typiques, vous approfondirez probablement le sujet et améliorerez votre connaissance de l'API REST dans en tout cas.

Passons maintenant du simple au complexe, en commençant par la terminologie de base et en poursuivant avec une section avec des questions plus complexes.

1. Qu'est-ce que le REPOS ?

Réponse : Il existe trois termes utilisés pour faire référence à REST qui sont souvent considérés comme la même chose, mais ce n'est pas tout à fait vrai. Ces termes sont REST, REST API et RESTful API. Il y aura maintenant une réponse à propos de REST, le terme signifie Representational State Transfer et est un style architectural basé sur le protocole HTTP (Hypertext Transfer Protocol) pour développer des applications qui ont un front-end et/ou une intégration avec des systèmes externes. REST décrit les directives que les services API conçus doivent suivre. Ces principes garantissent que les requêtes sont transmises entre le client et le serveur via HTTP.

2. Qu'est-ce que l'API REST ?

Réponse : Une API est une interface de programmation qui permet à des applications individuelles de communiquer et d'échanger des données. Par exemple, une application de livraison de nourriture peut utiliser l'API Google Maps pour suivre l'emplacement du coursier et l'afficher sur une carte. Une API REST est une API qui suit les principes de REST, traitant toutes les données comme des ressources, chacune représentée par un identifiant de ressource uniforme (URI) unique.

3. Qu'est-ce qu'une API RESTful ?

Réponse : Une API RESTful est une API conçue selon les règles (ou on peut aussi dire « principes ») de REST. En d’autres termes, la différence entre l’API REST et l’API RESTful est terminologique. Le premier cas fait référence à un ensemble de règles REST, et le second fait référence à la mise en œuvre d'une API spécifique suivant les règles REST. Le terme API RESTful est souvent remplacé par API REST ou même REST uniquement par souci de concision. Lorsque les analystes système dessinent des flèches intitulées REST sur un diagramme d'application, ils désignent une API RESTful.

4. Quels sont les deux grands principes de REST ?

Réponse : Les requêtes API REST doivent suivre deux principes de base : Séparation en client et serveur : L'interaction entre le client et le serveur s'effectue sous forme de requêtes et de réponses. Seuls les clients peuvent faire des requêtes et seuls les serveurs peuvent envoyer des réponses pour fonctionner indépendamment les uns des autres. Protocole unique : L'interaction entre le client et le serveur doit s'effectuer à l'aide d'un protocole unique. Pour REST, ce protocole est HTTP.

5. Quels autres principes de REST connaissez-vous ?

Réponse : Vous pouvez nommer au moins 4 autres principes. Les requêtes API REST ne stockent pas l'état sur le serveur et peuvent traverser des couches de serveurs et être mises en cache. Vous pouvez également envoyer du code exécutable aux clients dans la réponse du serveur. Serveur sans état : le serveur ne stocke aucune information sur les demandes/réponses passées. Chaque demande et réponse contient toutes les informations nécessaires pour compléter l'interaction. La communication sans état réduit la charge du serveur, économise de la mémoire et améliore les performances. Système en couches : des serveurs supplémentaires sont possibles entre le client et le serveur API sous forme de couches pour exécuter différentes fonctions. Dans un système construit sur les principes REST, les couches sont modulaires et peuvent être ajoutées et supprimées sans affecter les communications entre le client et le serveur. Mise en cache : les réponses du serveur indiquent si sa ressource peut être mise en cache afin que les clients puissent mettre en cache n'importe quelle ressource pour améliorer les performances. Code à la demande : le serveur peut envoyer du code exécutable aux clients dans sa réponse pour exécution dans l'application client.

6. Qu'est-ce qu'une ressource ?

Réponse : Dans REST, chaque objet accessible côté serveur est désigné comme ressource. Une ressource est un objet auquel sont associés un type, des données, une relation avec d'autres ressources sur le serveur et une liste de méthodes pouvant être utilisées pour l'utiliser. Par exemple, une ressource peut être un fichier HTML ou texte, un fichier de données, une image ou une vidéo, ou un fichier de code exécutable. Une ressource est identifiée par un Uniform Resource Identifier ou URI. Les clients accèdent aux ressources en utilisant leurs URI dans les requêtes HTTP.

7. Qu'est-ce qu'une URL ?

Réponse : URI signifie Uniform Resource Identifier. Il s'agit d'une chaîne qui identifie une ressource sur le serveur. Chaque ressource possède son propre URI unique qui, lorsqu'il est inclus dans une requête HTTP, permet aux clients d'accéder à cette ressource et d'y effectuer des actions. Le processus de référence à une ressource par son URI est appelé « adressage ».

8. Qu'est-ce que le CRUD ?

Réponse : CRUD signifie « Créer, Lire, Mettre à jour, Supprimer ». Ce sont les quatre principales actions pouvant être effectuées sur les bases de données via l'API REST. Chaque action possède sa propre méthode de requête HTTP :

• Créer = POST
• Lire = OBTENIR
• Mettre à jour = METTRE
• Supprimer = SUPPRIMER

9. Qu'entend-on par charge utile dans la réponse du serveur ?

Réponse : La charge utile de la réponse HTTP fait référence aux données de ressources demandées par le client. Ceci est également brièvement appelé « charge utile de réponse HTTP ». Ces données peuvent être au format JSON, XML, HTML, images, fichiers, etc., selon ce que fournit exactement le serveur.

10. Qu'est-ce que la messagerie REST ?

Réponse : La messagerie dans REST fait référence à l'échange de messages entre le client et le serveur. La communication commence toujours lorsque le client envoie une requête HTTP au serveur. Le serveur traite cette demande, puis renvoie une réponse HTTP qui indique l'état de la demande et toutes les ressources demandées par le client.

11. Qu'est-ce qu'un courtier de messages dans REST ?

Réponse : Dans le contexte de REST, le terme « courtier de messages » est un middleware qui sert à transmettre des messages entre différents composants ou systèmes dans une application distribuée. Le courtier peut fournir un échange de données asynchrone, une mise en file d'attente des messages et un traitement des messages entre différents modules du système.

Les courtiers de messages peuvent être utilisés pour gérer des opérations asynchrones ou envoyer des notifications. Le courtier de messages n'est pas un élément REST natif car... REST se concentre sur la communication synchrone entre le client et le serveur à l'aide de requêtes HTTP.

12. Quelles méthodes de requête HTTP sont prises en charge par REST ?

Réponse : La méthode de requête HTTP spécifie l'action souhaitée que le serveur effectuera sur la ressource. Dans REST, il existe quatre méthodes principales pour effectuer des requêtes HTTP d'un client vers un serveur :

• GET : Demande une ressource au serveur, cette méthode est en lecture seule.
• POST : crée une nouvelle ressource sur le serveur.
• PUT : Met à jour une ressource existante sur le serveur.
• DELETE : Supprime une ressource du serveur.

13. Quelle est la différence entre les méthodes POST et PUT ?

Réponse : POST sert à créer une ressource sur le serveur tandis que PUT sert à remplacer une ressource à un URI spécifique par une autre ressource. Si vous utilisez PUT sur un URI auquel une ressource est déjà associée, PUT la remplacera. S'il n'y a aucune ressource à l'URI spécifié, PUT en crée une. PUT est idempotent, ce qui signifie que l’appeler plusieurs fois entraînera la création d’une seule ressource. Cela se produit parce que chaque appel remplace une ressource existante (ou en crée une nouvelle s'il n'y a rien à remplacer). POST n’est pas idempotent. Si par exemple vous appelez POST 10 fois, alors 10 ressources différentes seront créées sur le serveur, chacune avec son propre URI. Bien que rarement utilisées, les réponses POST peuvent être mises en cache, mais pas les réponses PUT. Les requêtes POST sont généralement considérées comme impossibles à mettre en cache, mais elles peuvent être mises en cache lorsqu'elles contiennent des informations claires sur la « fraîcheur » des données. Une réponse plus détaillée est que la réponse à une requête POST (ou PATCH) peut être mise en cache si les données sont "fraîches" et que l'en-tête Content-Location (en-US) est défini, mais cela est rarement implémenté. Par conséquent, la mise en cache POST doit être évitée si possible.

14. Quelles sont les principales parties d’une requête HTTP ?

Réponse : Dans REST, il existe les composants de base suivants d'une requête HTTP : La méthode de requête qui sera adressée à la ressource (c'est-à-dire GET, POST, PUT, DELETE). Un URI qui identifie la ressource demandée sur le serveur. Version HTTP – c'est-à-dire quelle version doit figurer dans la réponse du serveur. L'en-tête de la requête HTTP contient des métadonnées sur la requête, telles que l'agent utilisateur, les formats de fichiers acceptés par le client, le format du corps de la requête, la langue, les préférences de mise en cache, etc. Le corps d'une requête HTTP, il contient toutes les données associées à la requête. . Cela n'est nécessaire que si la demande consiste à modifier des données sur le serveur à l'aide des méthodes POST ou PUT.

15. Quelles sont les principales parties d'une réponse HTTP ?

Réponse : Les réponses HTTP sont envoyées du serveur au client. Ils informent le client de la réalisation (ou non) de l'action demandée et de la livraison des ressources éventuellement demandées. Il existe quatre composants principaux d'une réponse HTTP : Version HTTP utilisée. Barre d'état avec l'état de la demande et le code d'état de la réponse HTTP. En-tête de réponse HTTP avec des métadonnées sur la réponse, notamment l'heure, le nom du serveur, l'agent utilisateur, les formats de fichiers de ressources renvoyés et les informations de mise en cache. Corps de réponse HTTP contenant des données sur la ressource demandée par le client

16. Nommez au moins 3 codes pour les réponses réussies du serveur HTTP

Réponse : Le serveur renvoie les codes d'état de fonctionnement suivants lorsque la demande est traitée avec succès :

• 200 OK : la demande a été exécutée avec succès.
• 201 Créé : la demande a abouti et la ressource a été créée.
• 202 Accepté : Ce statut signifie que le serveur a accepté la demande du client mais n'a pas terminé son traitement. Le traitement peut être asynchrone.

17. Nommez au moins 4 codes de réponse HTTP du serveur lors de la redirection d'une requête

Réponse : Le serveur renvoie les codes d'état suivants lors de la redirection d'une demande :

• 301 Déplacé de façon permanente : ce statut indique au client que la ressource demandée a été définitivement déplacée vers une autre URL et que le client doit accéder à la nouvelle URL pour accéder à la ressource.
• 302 Trouvé : cet état indique que la ressource a été temporairement déplacée vers une autre URL et que le client doit temporairement utiliser la nouvelle URL.
• Redirection temporaire 307 : similaire à 302, mais le client doit utiliser la même méthode de requête lors de l'accès à la nouvelle URL.
• Redirection permanente 308 : similaire à 301, mais le client doit utiliser la même méthode de requête lors de l'accès à la nouvelle URL.

18. Nommez au moins 4 codes pour les réponses infructueuses du serveur HTTP.

Réponse : Le serveur renvoie les codes suivants lorsque la demande échoue :

• 400 Bad Request : la demande n'a pas été complétée en raison d'une erreur dans la demande, telle qu'une faute de frappe ou des données manquantes.
• 401 Non autorisé : la demande n'a pas été complétée car le client n'est pas authentifié ou n'a pas l'autorisation d'accéder à la ressource demandée.
• 403 Interdit : La demande n'a pas été complétée car le client est authentifié mais n'est pas autorisé à accéder à la ressource demandée.
• 404 Not Found : la demande n'a pas été complétée car le serveur n'a pas pu trouver la ressource demandée.

19. Nommez au moins 3 codes d'erreur du serveur.

Réponse : Le serveur renvoie les codes suivants lorsqu'il y a une erreur sur le serveur :

• 500 Erreur interne du serveur : la demande n'a pas abouti en raison d'un problème inattendu avec le serveur.

• 502 Bad Gateway : la demande n'a pas été complétée en raison d'une réponse incorrecte du serveur en amont.

• 503 Service indisponible : le serveur n'a pas pu traiter la demande en raison d'une maintenance, d'une surcharge ou d'autres perturbations temporaires.

  
  

20. Quelle est la différence entre REST et GraphQL

Réponse : GraphQL est un langage de requête qui permet aux clients d'interroger uniquement les données dont ils ont besoin. Dans GraphQL, le client définit la structure et le format des données qu'il souhaite recevoir, et le serveur les renvoie en fonction de cette requête. La principale différence est que REST a un format de demande et de réponse fixe pour chaque ressource, tandis que GraphQL permet aux clients de définir leur demande et d'obtenir uniquement les informations dont ils ont besoin, ce qui la rend plus efficace et plus flexible à utiliser.

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

Réponse : REST et SOAP (Simple Object Access Protocol) sont deux approches pour créer des API. Il existe 3 différences principales entre eux :

• SOAP est un protocole strict pour créer des API sécurisées. REST n'est pas un protocole, mais un style architectural dicté par un ensemble de lignes directrices appelées principes REST. - Les API REST sont plus simples à créer, plus légères et généralement plus rapides que les API SOAP.
• Les API SOAP sont considérées comme plus sécurisées que les API REST, bien que celles-ci puissent toujours implémenter des fonctionnalités de sécurité pour les rendre assez sécurisées. - REST permet de mettre les réponses en cache, contrairement à SOAP.
• SOAP encode les données au format XML. - REST vous permet d'encoder des données dans n'importe quel format, bien que XML et JSON soient les plus populaires.

22. Quelle est la différence entre REST et AJAX ?

Réponse : JavaScript asynchrone ou AJAX est un ensemble de technologies de développement Web utilisées dans les applications Web. À la base, AJAX permet à une page Web d'envoyer des requêtes au serveur et de mettre à jour l'interface de la page sans avoir à mettre à jour la page entière.

Un client AJAX peut utiliser l'API REST dans ses requêtes, mais AJAX n'est pas obligé de fonctionner uniquement avec l'API REST. Les API REST peuvent communiquer avec n'importe quel client, qu'il utilise ou non AJAX.

Contrairement à REST, qui utilise des requêtes et des réponses HTTP pour échanger des messages, AJAX envoie ses requêtes au serveur à l'aide de l'objet XMLHttpRequest intégré à JavaScript. Les réponses du serveur sont exécutées par le code JavaScript de la page pour modifier son contenu.

23. Quelle est l'approche « Contract First » pour le développement d'API REST ?

Réponse : L'approche Contract First du développement d'API REST est une méthodologie dans laquelle la spécification et le contrat de l'API sont créés et définis avant le début du développement réel. Ce contrat constitue un document important qui définit comment les clients peuvent interagir avec l'API et quels résultats attendus seront obtenus à partir des diverses demandes.

24. Quels sont les avantages de Contrat d'abord ?

Réponse : Les avantages suivants de l’approche Contract First peuvent être mentionnés :

• Définition claire de l'API : la spécification et le contrat de l'API définissent la manière dont l'API doit interagir avec les clients.
• Réduire les risques : l'approbation préliminaire du contrat avec les clients permet de réduire le risque de malentendus et de non-réponse aux attentes en matière de développement d'API.
• Documentation améliorée : le texte du contrat sert souvent de documentation pour l'API, ce qui la rend plus facile à utiliser et à intégrer.

25. Quelle est l'approche Code First pour le développement d'API REST ?

Réponse : L'approche Code First du développement d'API REST est une méthodologie dans laquelle la fonctionnalité API est d'abord développée, puis une spécification API est automatiquement générée en fonction de cette fonctionnalité. La particularité de l'approche Code First est que les développeurs se concentrent sur l'écriture de la logique de l'API et utilisent des outils qui leur permettent de créer automatiquement une documentation et des spécifications basées sur cette logique.

De manière générale, les deux approches, Code First et Contract First, peuvent être combinées au sein d’un même projet de développement d’API. Dans ce cas, Code First est utilisé pour le prototypage rapide, suivi de Contract First pour formaliser le contrat.

J'espère que cet article vous sera utile pour préparer un entretien d'embauche ou pour rafraîchir vos connaissances sur l'API REST.