Table des matières[Cacher][Montrer]
- 1. Qu'entendez-vous par REST ?
- 2. Qu'entendez-vous par API REST ?
- 3. Qu'est-ce qu'une URI exactement ?
- 4. Quelles sont les caractéristiques des services Web RESTful ?
- 5. Quels sont les principes directeurs de REST ?
- 6. Mentionnez les méthodes HTTP prises en charge par REST.
- 7. Décrivez les restrictions imposées par une interface cohérente.
- 8. Qu'est-ce qu'une ressource REST exactement ?
- 9. Que signifie JAX-RS pour vous ?
- 10. Qu'est-ce qui distingue AJAX et REST l'un de l'autre ?
- 11. Pouvez-vous énumérer quelques inconvénients des services Web RESTful ?
- 12. Qu'est-ce qui distingue les techniques PUT et POST l'une de l'autre ?
- 13. Comment testez-vous les services Web RESTful ?
- 14. Décrivez une API REST dans le monde réel.
- 15. Comment fonctionne l'architecture de microservice ?
- 16. Qu'est-ce que la mise en cache exactement ?
- 17. Décrivez la charge utile.
- 18. Différencier SOAP Vs REST ?
- 19. Le protocole TLS (Transport Layer Security Protocol) peut-il être utilisé avec REST ?
- 20. Méthodes idempotentes : qu'est-ce que c'est ? Comment cela s'applique-t-il au monde des services Web RESTful ?
- 21. Quelle est la fonctionnalité de l'authentification de base HTTP ?
- 22. Pensez-vous que GraphQL est le meilleur choix pour créer une architecture de microservice ?
- 23. Quelles sont les principales distinctions entre les méthodes HTTP sûres et idempotentes ?
- 24. Qu'implique l'API JAX-RS par RESTful Root Resource Classes ?
- 25. Qu'est-ce que Postman exactement et pourquoi est-il utilisé ?
- 26. Comment les API REST sont-elles sécurisées ?
- Conclusion
L'évolution de REST a rendu les API incroyablement accessibles tout en révélant toute leur force et leur potentiel. Les API REST sont faciles à créer et à mettre en cache en raison de leur architecture orientée ressources.
De plus, au fil du temps, les API RESTful ont été les précurseurs d'autres développements importants tels que le cloud computing et la conception basée sur les microservices.
Par conséquent, il n'est pas surprenant que les développeurs d'API REST soient en demande aujourd'hui, étant donné qu'ils offrent aux entreprises qui utilisent des services RESTful un avantage concurrentiel. Les API REST sont une tendance de conception populaire.
De nombreuses entreprises informatiques veulent des connaissances sur l'API REST les développeurs de logiciels et posez des questions à ce sujet lors d'entretiens techniques.
Voici quelques-unes des questions d'entretien d'API REST les plus typiques qui vous aideront à être prêt pour des entretiens dans diverses entreprises si vous souhaitez travailler dans le domaine du développement d'API REST.
1. Qu'entendez-vous par REST ?
REST est un paradigme architectural pour la conception d'applications Web basées sur le protocole de transfert hypertexte (HTTP).
REST définit certaines normes que les services Web doivent respecter pour être considérés comme RESTful. Ces recommandations garantissent que les requêtes et les ressources sont transmises rapidement et efficacement entre le client et le serveur à l'aide de protocoles HTTP standardisés.
2. Qu'entendez-vous par API REST ?
Un lien logiciel à logiciel connu sous le nom d'interface de programmation d'application permet la communication et le partage de données entre des programmes autrement indépendants. Par exemple, un site Web d'actualités pourrait utiliser l'API Twitter pour découvrir automatiquement les tweets pertinents et les intégrer dans des reportages.
Une API qui adhère aux principes REST est connue sous le nom d'API REST, parfois appelée API RESTful. Dans une API REST, chaque élément de données est traité comme une ressource et reçoit une identité de ressource standard (URI) distincte.
Par exemple, l'API Twitter fait de chaque tweet une ressource récupérable disponible pour les clients. L'API Twitter peut être utilisée par les utilisateurs pour publier des tweets et effectuer d'autres tâches sur le site Web.
3. Qu'est-ce qu'une URI exactement ?
A réseau informatique ressource peut être référencée à l'aide d'un URI ou d'un identifiant de ressource uniforme. Il sert à séparer une ressource d'une autre. Les sources peuvent ou non être en ligne.
En raison de leur structure standard, les URI facilitent la connexion à différents types de ressources. L'emplacement ou le nom de la ressource est inclus dans les URI avec une chaîne de caractères.
L'URI est composé d'un chemin, d'un schéma, d'une requête et d'autres éléments, mais n'inclut pas le protocole.
A l'aide d'un protocole, les URL (Uniform Resource Locators) permettent de trouver des ressources sur Internet ou accessibles par celui-ci.
4. Quelles sont les caractéristiques des services Web RESTful ?
- Le paradigme client-serveur est le fondement du service.
- Le service peut accéder aux ressources via l'utilisation d'URI.
- Le service utilise le protocole HTTP pour acquérir des données/ressources, exécuter des requêtes et effectuer d'autres tâches.
- La messagerie est le nom de la méthode utilisée pour communiquer entre le client et le serveur.
- Ces services peuvent également implémenter le modèle architectural REST à l'aide des services SOAP.
- Pour réduire les appels au serveur pour le même type de requêtes répétitives, ces services utilisent également l'idée de la mise en cache.
5. Quels sont les principes directeurs de REST ?
Cinq critères doivent être remplis par les API REST :
Découplage client-serveur : Seule une série de requêtes et de réponses peut être utilisée pour communiquer entre le client et le serveur. Seuls les clients et les serveurs peuvent respectivement envoyer des requêtes et des réponses. Cette idée simple permet aux deux parties de fonctionner indépendamment l'une de l'autre.
Interface uniforme : il doit y avoir un protocole uniforme pour toutes les connexions client-serveur. Ce protocole pour REST est HTTP. Étant donné que chaque application demande et envoie des données en utilisant le même langage, une interface cohérente simplifie les intégrations.
Sans état : le serveur ne conserve aucun enregistrement des demandes ou réponses précédentes dans une communication sans état. Chaque demande et réponse fournit tous les détails nécessaires pour compléter l'échange. La communication sans état améliore la vitesse, économise de la mémoire et réduit le stress sur le serveur. De plus, cela évite le risque d'échec d'une demande en raison de données incomplètes.
Système en couches : les serveurs qui résident entre le client et le serveur d'API sont appelés couches. Ces serveurs supplémentaires exécutent une variété de services, tels que la détection du spam et l'optimisation de la vitesse. Les couches dans REST sont modulaires, ce qui signifie qu'elles peuvent être ajoutées et supprimées sans affecter les communications entre le client et le serveur d'API.
Cacheable : les clients peuvent mettre en cache toutes les ressources pour augmenter la vitesse si les réponses du serveur indiquent si la ressource est cacheable ou non.
Codage à la demande : En réponse, une API peut transmettre un code informatique exécutable aux clients. L'application cliente peut alors exécuter le code sur son propre back-end.
6. Mentionnez les méthodes HTTP prises en charge par REST.
Les méthodes HTTP prises en charge par REST sont :
- GET : cette méthode demande une ressource à l'URL spécifiée. Un corps de requête ne doit pas être inclus car il sera ignoré. Il pourrait être possible de le mettre en cache localement ou sur le serveur.
- POST : cette méthode envoie des données à un service pour traitement, et le service doit normalement renvoyer une ressource nouvelle ou modifiée.
- PUT : la ressource est mise à jour à l'URL de la demande.
- SUPPRIMER : la ressource est supprimée à l'URL de la demande.
- Options : identifie les méthodes prises en charge.
- HEAD : les métadonnées de l'URL de la requête sont renvoyées.
7. Décrivez les restrictions imposées par une interface cohérente.
Afin de séparer le client du serveur, une interface cohérente est nécessaire.
Pour obtenir une interface cohérente, les quatre contraintes suivantes sont requises :
- Identification des ressources : les demandes des clients doivent utiliser des ID de ressource standard pour identifier les ressources (URI)
- Manipulation des ressources à l'aide de ces représentations : les clients disposent de toutes les informations nécessaires pour pouvoir modifier l'état des ressources lorsqu'ils obtiennent une représentation des ressources du serveur.
- Messages autodescriptifs : les messages incluent toutes les métadonnées et autres informations nécessaires pour que le destinataire puisse les comprendre.
- L'hypermédia en tant que moteur d'état de l'application : le canal de communication client-serveur est l'hypermédia, tel que HTML, et les clients n'ont pas besoin de documentation spécifique à l'API pour comprendre les réponses du serveur.
8. Qu'est-ce qu'une ressource REST exactement ?
Les ressources sont les composants fondamentaux d'un service Web RESTful dans une architecture REST. Ils incluent toutes les informations cruciales auxquelles un client API doit accéder.
Tout type de ressources, telles qu'une page HTML, une image, une vidéo ou tout autre élément nécessaire à une activité d'API, est accessible via le serveur dans un système client-serveur.
Les ressources sont identifiées par un Uniform Resource Identifier. Texte, JSON ou XML sont toutes des représentations acceptables de ressources. Cela dit, il n'y a aucune limitation sur le format de la représentation.
9. Que signifie JAX-RS pour vous ?
Il est plus simple de créer des services Web RESTful en Java grâce à l'API Java pour les services Web RESTful, souvent appelée JAX-RS. Les développeurs peuvent décrire les ressources et les opérations pouvant être effectuées sur celles-ci à l'aide des annotations fournies.
10. Qu'est-ce qui distingue AJAX et REST l'un de l'autre ?
Ajax:
- Ajax est un groupe de technologies qui permet la mise à jour dynamique de Interface utilisateur éléments sans avoir à recharger la page.
- Ajax supprime la communication asynchrone entre le client et le serveur.
DU REPOS:
- REST demande une communication entre le serveur et le client.
- L'utilisation des ressources est importante pour la structure de l'URL et le modèle de demande/réponse utilisé par REST.
11. Pouvez-vous énumérer quelques inconvénients des services Web RESTful ?
Les séances ne peuvent pas être maintenues car les services adhèrent à la notion d'apatridie. (Le client est responsable de transmettre l'identifiant de session tout au long de la simulation de la session.)
Les contraintes de sécurité ne sont pas fondamentales pour REST. Les protocoles qui l'utilisent héritent des précautions de sécurité. Par conséquent, il est important de faire preuve de prudence lors de la mise en place de mesures de sécurité, telles que l'intégration d'authentifications basées sur SSL/TLS.
12. Qu'est-ce qui distingue les techniques PUT et POST l'une de l'autre ?
PUT:
- Il n'y a pas de cache pour les réponses PUT.
- Idempotent (c'est-à-dire que plusieurs requêtes donneront le même résultat)
- la charge utile de la demande met à jour ou remplace la ressource cible.
POSTER:
- idempotent non (c'est-à-dire que plusieurs requêtes produiront des multiples de la même ressource)
- Le serveur Web traite la charge utile de la demande en fonction de la ressource prévue.
- Si l'en-tête cache-control approprié est inclus, les réponses POST peuvent être mises en cache.
13. Comment testez-vous les services Web RESTful ?
Les tests de services Web RESTful peuvent être aidés par un certain nombre d'outils, notamment Swagger et Postman. L'inspection des paramètres de requête tels que les paramètres de requête, les en-têtes et les en-têtes de réponse est rendue possible par l'abondance de fonctionnalités de ce dernier.
Postman peut être utilisé pour envoyer des requêtes aux points de terminaison et afficher les résultats. Et XML et JSON peuvent être créés à partir de ces réponses.
Postman et Swagger offrent tous deux des fonctionnalités extrêmement comparables. D'autre part, Swagger offre également des fonctionnalités telles que la documentation des terminaux.
14. Décrivez une API REST dans le monde réel.
- Les sites Web de voyage et de billetterie peuvent tirer parti des horaires de vol et des tarifs que les compagnies aériennes mettent à disposition via les API.
- Pour que les applications de cartographie et de navigation (comme Google Maps) puissent les utiliser, les agences de transport public rendent souvent leurs données accessibles au public en temps réel via des API.
- Les applications météo utilisent des API ouvertes qui échangent des données météorologiques pour afficher des informations météorologiques.
- Les développeurs peuvent accéder aux données cartographiques de Google Maps via un certain nombre de ses API hébergées. Ces API sont utilisées par les développeurs pour intégrer des cartes dynamiques dans leurs applications et sites Web.
15. Comment fonctionne l'architecture de microservice ?
- Les demandes sont envoyées par différents clients utilisant différents appareils.
- Après avoir confirmé l'identité des clients, les fournisseurs d'identité fournissent des jetons de sécurité.
- Les demandes des clients sont gérées par API Gateway.
- Tout le matériel du système est conservé en tant que contenu statique.
- L'outil de gestion vérifie l'équilibre des services sur les nœuds et les défauts éventuels.
- La découverte du chemin de communication entre les microservices est facilitée par la découverte de services.
- Les centres de données et les serveurs proxy constituent des systèmes de réseau dispersés appelés réseaux de diffusion de contenu.
- Les services à distance permettent d'accéder aux informations à distance.
16. Qu'est-ce que la mise en cache exactement ?
La pratique consistant à conserver temporairement une copie d'une réponse de serveur quelque part (comme la mémoire d'un ordinateur) afin d'y accéder plus tard plus rapidement est connue sous le nom de mise en cache.
La mise en cache améliore la vitesse du serveur lors de l'utilisation des API REST en réduisant la quantité de travail que le serveur doit effectuer pour satisfaire la demande. Les applications qui utilisent l'API s'exécutent plus rapidement grâce à la mise en cache, car elles n'ont pas à soumettre une nouvelle requête chaque fois qu'elles ont besoin d'une ressource.
Le champ Cache-Control de l'en-tête de réponse HTTP contient des informations sur la durée pendant laquelle une ressource peut être mise en cache par le client avant de devoir y accéder à nouveau.
17. Décrivez la charge utile.
La charge utile dans REST fait référence aux informations contenues dans le corps de la réponse HTTP. Le client a utilisé la technique GET pour demander les données en question.
Le document contenant le texte du tweet et tous les fichiers nécessaires pour mettre le tweet sur un site Web seront inclus dans la charge utile, par exemple, si vous demandez à l'API Twitter un tweet spécifique. De plus, la charge utile peut être incluse dans la requête HTTP à l'aide de la méthode POST.
18. Différencier SAVON Vs REST?
- Contrairement à SOAP, qui ne peut gérer que XML, REST permet une plus large gamme de formats de ressources, notamment XML, texte, HTML, images, vidéo, etc.
- Lorsque la sécurité est cruciale pour les applications en ligne, SOAP est utile. REST ne peut pas être utilisé lorsque les transactions doivent être effectuées en toute sécurité car il n'est pas particulièrement sécurisé.
- Étant donné que SOAP n'est qu'un protocole, REST peut l'utiliser dans ses services Web, mais pas l'inverse.
- Alors que REST n'est qu'un modèle architectural utilisé pour développer des services Web et respecte certaines limitations telles que la configuration client-serveur, l'absence d'état, la réponse pouvant être mise en cache, les systèmes en couches et l'interface cohérente, SOAP est un protocole qui fonctionne sur des normes particulières qui doivent être rigoureusement respectées. à.
- Alors que REST utilise des identificateurs de ressources universels (URI), SOAP utilise des interfaces de service pour fournir ses fonctionnalités aux applications clientes. REST a un besoin de bande passante inférieur à celui de SOAP car les messages SOAP sont plus riches en informations.
19. Le protocole TLS (Transport Layer Security Protocol) peut-il être utilisé avec REST ?
En fait, nous le pouvons. La communication entre le client REST et le serveur est cryptée via TLS, et le protocole donne également aux clients un moyen d'authentifier les serveurs.
Du fait qu'il s'agit du remplacement du Secure Socket Layer, il est utilisé pour la communication sécurisée (SSL). La mise en œuvre de services Web RESTful est réussie avec HTTPS car il coopère efficacement avec TLS et SSL.
Le REST hérite des caractéristiques du protocole qu'il implémente, ce qui est une chose à noter ici. Par conséquent, les protections de sécurité dépendent du protocole utilisé par REST.
20. Méthodes idempotentes : qu'est-ce que c'est ? Comment cela s'applique-t-il au monde des services Web RESTful ?
Lorsque l'URI est le même, certaines méthodes HTTP d'une requête ont le même impact sur le serveur, qu'elles soient livrées une ou plusieurs fois. Les techniques idempotentes sont ce que l'on appelle.
Par exemple, quel que soit le nombre d'exécutions d'un URI utilisant la méthode GET, le serveur obtiendra toujours le même résultat. Les méthodes idempotentes incluent GET, PUT et PATCH, pour n'en nommer que quelques-unes.
Les méthodes HTTP idempotentes sont parmi celles utilisées par RESTful Applications Web. Ils sont nécessaires pour garantir la cohérence des activités des services Web RESTful.
Les clients qui utilisent des API REST peuvent faire des erreurs de code qui forcent une API REST à effectuer des demandes répétées accidentellement. Ces appels peuvent entraîner une mauvaise utilisation des ressources.
21. Quelle est la fonctionnalité de l'authentification de base HTTP ?
Lors de l'utilisation de l'authentification de base dans le cadre des API, l'utilisateur doit soumettre le nom d'utilisateur et le mot de passe, qui sont concaténés par le navigateur sous la forme "nom d'utilisateur : mot de passe" et codés en base64.
À chaque requête HTTP du navigateur, la valeur encodée est fournie comme valeur pour l'en-tête « Authorization ». Étant donné que les informations d'identification sont simplement codées, il est recommandé d'utiliser ce formulaire lors de l'envoi de requêtes HTTPS car elles ne sont pas sécurisées et peuvent être interceptées par n'importe qui si les protocoles de sécurité ne sont pas utilisés.
22. Pensez-vous que GraphQL est le meilleur choix pour créer une architecture de microservice ?
Les microservices et GraphQL vont parfaitement ensemble car GraphQL garde votre architecture de microservice secrète pour vos clients.
Du front-end, vous voulez que toutes vos données proviennent d'une seule API, tandis que du back-end, vous voulez les diviser en microservices. La meilleure technique que je connaisse pour atteindre les deux consiste à utiliser GraphQL.
Il vous permet de diviser votre backend en microservices tout en donnant à chaque application une API unique et en permettant des jointures entre les données de divers services.
23. Quelles sont les principales distinctions entre les méthodes HTTP sûres et idempotentes ?
Les méthodes idempotentes produisent le même résultat lorsqu'elles sont invoquées une ou plusieurs fois via la même requête. La méthode PUT est idempotente.
Tous les moyens sûrs sont idempotents, mais toutes les méthodes idempotentes ne sont pas sûres puisque les méthodes sûres ne modifient pas les ressources. Par exemple, GET est sécurisé car il ne fait que récupérer des données et ne modifie pas la ressource.
De plus, il est idempotent, ce qui signifie qu'il renverra toujours la même réponse lorsqu'il sera invoqué.
24. Qu'implique l'API JAX-RS par RESTful Root Resource Classes ?
Java Enterprise Edition fournit des classes et des interfaces conformes aux exigences de l'API JAX-RS. Avec l'aide de JAX-RS, la création de services Web Java dans le style architectural REST est facilitée.
Dans l'API JAX-RS, les classes de ressources racine ne sont que des "objets Java anciens", ou POJO. Afin de mettre en œuvre les ressources Web nécessaires, ils utilisent des annotations JAX-RS.
Soit ils ont des annotations @path, soit au moins une de leurs méthodes a des annotations @path. Ils peuvent être résumés en classes Java avec des méthodes pour traiter les points de terminaison API.
25. Qu'est-ce que Postman exactement et pourquoi est-il utilisé ?
Un outil de développement d'API appelé Postman est utilisé pour créer, tester et modifier les API. Cet outil peut être utilisé par les développeurs pour toutes les fonctionnalités dont ils ont besoin pour une API. Il simplifie et facilite le travail des développeurs.
Postman facilite la création de diverses requêtes HTTP, notamment GET, POST, PUT et PATCH, la sauvegarde d'environnements pour une utilisation ultérieure et la conversion d'API en code dans plusieurs langages différents.
Chaque étape du cycle de l'API est simplifiée avec Postman et la coopération est simplifiée pour un développement plus rapide de l'API.
De plus, il permet aux développeurs de gérer la documentation, les spécifications, les cas de test, les processus et les catalogues d'API.
26. Comment les API REST sont-elles sécurisées ?
Étant donné que les API REST n'utilisent pas de protections de sécurité aussi rigoureuses que les API SOAP, les données sensibles ne doivent pas être envoyées ou récupérées à l'aide de celles-ci.
Cependant, les API REST dignes de confiance continuent d'intégrer des contrôles de sécurité pour des transmissions de données sûres et fiables.
- Authentification et autorisation : chaque requête adressée à l'API doit passer ces deux vérifications. La vérification de l'identité du client via l'authentification et la validation qu'il a le droit d'accéder aux ressources demandées via l'autorisation sont deux processus différents.
- Validation : avant que l'API n'accorde l'accès à ses ressources, les demandes doivent toujours être vérifiées pour détecter tout code potentiellement dangereux après l'authentification et l'autorisation. Un serveur serait ainsi ouvert à une attaque par injection.
- Validation : avant que l'API n'accorde l'accès à ses ressources, les demandes doivent toujours être vérifiées pour détecter tout code potentiellement dangereux après l'authentification et l'autorisation. Un serveur serait ainsi ouvert à une attaque par injection.
- Cryptage : le cryptage TLS/SSL protège la connexion entre le client et le serveur et empêche les pirates d'intercepter les demandes et les réponses.
- Les techniques de limitation de débit, telles que les limites et la limitation, protègent les serveurs des attaques par force brute comme les DDoS qui visent à les dégrader ou à les planter.
- Aucune information sensible dans les URI : les URI des ressources ne doivent contenir aucune donnée protégée (comme un nom d'utilisateur, un mot de passe ou un jeton d'authentification).
Conclusion
Toutes nos félicitations! Plusieurs questions d'entretien de l'API REST de base à complexe et leurs solutions respectives sont désormais à portée de main.
Maintenant que vous avez une bonne idée de la façon de répondre à certaines des questions d'entretien typiques de l'API REST, vous pouvez continuer à répondre aux entretiens. La prochaine étape dépend de vos objectifs.
Visiter Série d'entrevues avec Hashdork pour se préparer aux entretiens.
Soyez sympa! Laissez un commentaire