Tutoriel de l'API Rest: architecture et contraintes de l'API REST

rest api tutorial rest api architecture

Dans ce didacticiel, nous découvrirons l'API REST, les services Web, l'architecture de l'API REST, les contraintes de l'API REST et comment tester une API à l'aide de POSTMAN:

Conditions préalables: Connaissance de base des services Web.

Vérifier ici pour avoir une compréhension claire des services Web.

Ce que vous apprendrez:

• Qu'est-ce que l'API REST?
  • Différence entre SOAP et REST
  • Pourquoi choisir REST plutôt que SOAP?
    • Pourquoi Postman?
  • Architecture d'API REST
  • Contraintes de l'API REST
  • Qu'est-ce que POSTMAN?
  • Comment tester l'API avec Postman?
    • Installation
• Conclusion
  • lecture recommandée

Qu'est-ce que l'API REST?

L'API est simplement une interface, qui est utilisée par les composants logiciels pour communiquer entre eux. Un service est une fonction bien définie, autonome et qui ne dépend d'aucun autre service.

Un service Web est un type d'API, presque tous fonctionnent sur HTTP. Lorsqu'une API Web est développée à l'aide de l'architecture REST, elle est appelée API Web REST.

À partir de maintenant, il existe deux types de services Web,

• SAVON
• DU REPOS

Différence entre SOAP et REST

Pourquoi choisir REST plutôt que SOAP?

Les points ci-dessous expliquent les raisons d'opter pour REST plutôt que SOAP.

• Il est très utile pour développer et tester des API Web.
• REST nécessite moins de bande passante.
• Nous pouvons utiliser AJAX pour les API Web basées sur REST.
• Cela nécessite moins de frais généraux d'analyse.
• La taille de la charge utile créée par JSON est de taille moindre.

Il existe de nombreux clients / outils disponibles sur le Web, ce qui nous permet de consommer des services Web RESTful.

Elles sont:

• Facteur
• Client de repos avancé
• Client DHC Rest
• Demandeur
• Insomnie
• Assertible
• Affiche

Pourquoi Postman?

• Il affiche toutes les options disponibles.
• Postman a une fonctionnalité supplémentaire (connue sous le nom de Runner).
• Interface utilisateur conviviale et facile à utiliser.
• Groupe / membres communautaires plus importants.

Architecture d'API REST

Il s'agit principalement de l'architecture du Web dans un style architectural logiciel. Il est destiné aux systèmes hypermédia distribués. Une API RESTful tire directement parti des méthodologies HTTP définies par le protocole RFC 2616.

Peu de définitions

FEU signifie Interface de programmation d'application. Il s'agit d'un ensemble de définitions de sous-programmes, de protocoles et d'outils permettant de créer le logiciel d'application.

Services Web sont des codes de programme contenant des données / méthodes intégrées. Ceux-ci sont déployés par l'organisation sur Internet pour communiquer avec les utilisateurs, les applications tierces, etc. Pour la communication des messages, le XML est principalement utilisé comme système de messagerie. XML encode simplement toutes les communications entre les utilisateurs et les applications.

HTTP signifie Hypertext Transfer Protocol, utilisé par le World Wide Web. Il définit la manière dont les messages sont formatés et transmis, et quelles actions les serveurs Web et les navigateurs entreprennent en réponse à diverses commandes.

Style architectural, ceux-ci sont caractérisés par les caractéristiques utilisées pour créer une structure et même la rendre unique. Les styles sont de deux types: interface en couches et uniforme.

DÉTESTER : Également appelé identificateur de ressource uniforme. Il identifie une ressource (document texte, fichier image, etc.).
URL: Également connu sous le nom de localisateur de ressources uniformes. C'est un sous-ensemble des URI, qui inclut un emplacement réseau.
URNE : Également connu sous le nom de nom de ressource uniforme, il s'agit d'un sous-ensemble d'URI, qui incluent un nom dans un espace donné, mais pas d'emplacement.

Par exemple,

http://elearning.com/amazon/restapi.html#books

Ici, dans l'exemple ci-dessus

DÉTESTER : http://elearning.com/amazon/restapi.html#posts
URL : http://elearning.com/amazon/restapi.html
URNE : elearning.com/amazon/restapi.html#posts

ce qui ouvre un fichier .jar

Par conséquent, une URL est un URI qui identifie une ressource et fournit également les moyens de localiser la ressource en décrivant la manière d'y accéder.

Ainsi, chaque URL peut être un URI mais l'inverse n'est pas vrai.

Un service RESTful est exposé via un URL (Uniform Resource Locator). Il s'agit d'un nom logique qui sépare l'identité de la ressource de ce qui est accepté ou renvoyé.

Un exemple d'architecture REST:

Contraintes de l'API REST

Une interface API est dite RESTful si elle remplit les contraintes suivantes:

• Interface uniforme: Cela signifie que, quel que soit le client que nous utilisons, le concept de base de la mise en œuvre et de l'utilisation des services REST restera le même. Toutes les API REST développées doivent avoir une approche commune du développement.
• Apatride: Cela signifie qu'aucune session ne doit être stockée. Ainsi, le serveur ne stockera aucune requête HTTP envoyée par un client. Par conséquent, pour un serveur, chaque requête HTTP est une nouvelle requête. Peu importe, combien de fois la demande est faite ou le client est unique ou non.
• Cacheable: La mise en cache signifie la fréquence à laquelle les données et les réponses sont accédées à partir d'un cache au lieu du serveur. Le concept de mise en cache est applicable lors de l'envoi de la demande client. L'amélioration des performances se fait donc côté client.
• Serveur client: Le serveur et les clients sont indépendants l'un de l'autre en termes de mise en œuvre. Un client doit uniquement envoyer l'URI de la demande avec ou sans authentification. Ensuite, le serveur fait le reste de l'étape, c'est-à-dire une réponse.
• Système en couches: Le client ne peut envoyer que la demande au serveur en tant qu'URI de ressource. Mais alors, avant que la requête ne soit envoyée au serveur, il existe l'API REST, qui nous fournit l'architecture du système en couches. Cela signifie que nous pouvons avoir une API déployée sur un serveur, les données sont déployées sur un autre serveur et l'authentification sur un autre serveur.
• Code à la demande (facultatif): Parfois, un client peut avoir besoin de plus qu'une réponse. L'API REST nous permet d'envoyer un code exécutable en réponse (ce code exécutable peut être un widget ou n'importe quel contrôle). Cependant, il est complètement facultatif que nous ayons activé / implémenté cette fonctionnalité.

Quelques terminologies supplémentaires liées à l'API Rest:

Point final : C'est la référence à une URL qui accepte les requêtes Web. Un service Web est adressable à l'aide d'une référence de point de terminaison.
Par exemple, Http: // {Domain_URL} //librarygr/libraries.xml

Ressources : Il s'agit d'un sous-ensemble de Endpoint. Normalement, les points de terminaison exposent certains objets qui peuvent être utilisés via les services Web. Les ressources sont spécifiquement cette partie d'un objet sur l'URI du point de terminaison.
Par exemple, Http: // {Domain_URL} // api / pg_library / ornithology / swan

Charge utile : La charge utile correspond aux informations envoyées lors de l'exécution de l'opération POST ou PUT. Ce sont les informations spécifiées dans le corps de la requête HTTP.

Les charges utiles sont envoyées au format JSON, Par exemple,

Paramètres :

Nous pouvons passer des paramètres de deux manières.

Paramètres de requête : Utile pour accéder aux paires clé / valeur dans la chaîne de requête de l'URL (la partie après le?)

Meilleur exemple

http://jsonplaceholder.typicode.com/posts/?id=3

Paramètres de chemin: Il est utile de faire correspondre une partie de l'URL en tant que paramètre. Nous pouvons envoyer des informations en tant que paramètre de chemin de la manière suivante: Form-data, x-www-form-urlencoded, raw, binary.

Meilleur exemple:

https://api.github.com/gists/49b05378bb8920d5b4ec54efc27103e2/comments

Qu'est-ce que POSTMAN?

POSTMAN est un client REST, simplement une application fournie avec le navigateur Chrome. Il est en cours de développement, en gardant à l'esprit les développeurs pour faciliter le test des appels API. Il possède sa propre interface graphique pour envoyer les requêtes API et lire les réponses API.

Nous pouvons effectuer les tests de l'API REST à la fois manuellement et par automatisation.

Dans la section suivante, nous allons apprendre comment tester manuellement l'API Web à l'aide du client POSTMAN.

Comment tester l'API avec Postman?

Installation

Nous devons accéder au Chrome Web Store . Dans le navigateur Chrome, recherchez Postman. Cliquez sur ici pour l'ajouter au bouton Chrome.

Une fois qu'il est installé avec succès, nous pouvons trouver POSTMAN sous l'application Chrome. Cliquez simplement sur l'icône Postman pour ouvrir POSTMAN. Il faudra du temps pour se lancer pour la première fois.

Veuillez vous référer à l'URL suivante pour comprendre comment utiliser FACTEUR comme un outil.

Conditions préalables: Une connexion Internet est requise pour accéder aux services déployés sur le Web. En cas d'accès aux services déployés localement, assurez-vous que des droits suffisants, des privilèges sont accordés à l'utilisateur qui exécute le test sur POSTMAN.

URI de ressource factice: Dans ce tutoriel, nous utiliserons un URI factice au lieu d'un URI réel. Il nous donnera les réponses souhaitées mais des modifications ne peuvent pas être apportées au serveur.

http://jsonplaceholder.typicode.com

Étapes de navigation :

#1) Une fois l'application POSTMAN lancée, nous pouvons voir la page de demande par défaut.

quel est le meilleur logiciel de suppression de logiciels malveillants

#deux) Nous pouvons voir la liste des appels d'API en cliquant sur le menu déroulant. En sélectionnant l'une des options de la liste déroulante, nous pouvons demander l'appel d'API au serveur.

# 3) Cliquez sur le bouton Variable d'environnement dans le coin supérieur droit d'un POSTMAN. Définissez l'environnement spécifique dans lequel nous allons tester. Nous pouvons le sauvegarder pour une exécution future.

# 4) L'environnement enregistré peut être accessible à partir de la liste déroulante Environnement.

# 5) Ensuite, nous devons définir l'URI de la ressource dans la zone donnée.

# 6) Cliquez sur le bouton Paramètres à côté du champ URI de la ressource pour spécifier les paramètres de la requête

# 7) Cliquez sur l'onglet Autorisation, sélectionnez le type d'autorisation dans la liste déroulante et définissez toute autorisation souhaitée ou, vous pouvez simplement la laisser comme Aucune autorisation.

# 8) Cliquez sur l'onglet En-têtes et définissez les en-têtes requis comme le type de contenu

# 9) Cliquez sur l'onglet Corps, sélectionnez le bouton radio des données de formulaire. Spécifiez les paramètres de corps requis qui doivent être envoyés avec l'URL de la demande

# dix) Cliquez sur l'onglet Corps, sélectionnez le bouton radio x-www-form-urlencoded. Spécifiez les paramètres de corps requis qui doivent être envoyés comme codés, avec l'URL de la demande

#Onze) Cliquez sur l'onglet Corps, sélectionnez le bouton radio «brut». Spécifiez les paramètres de corps requis qui doivent être envoyés avec l'URL de la demande. C'est au format JSON réel

N ° 12) Cliquez sur l'onglet Corps, sélectionnez le bouton radio «binaire». Spécifiez les paramètres de corps requis (normalement sous forme de fichier) qui doivent être envoyés avec l'URL de la demande.

N ° 13) Une fois que nous avons configuré tous les détails comme indiqué ci-dessus, nous pouvons désormais «envoyer» la demande. De plus, nous pouvons enregistrer la demande d'envoi sous le nom request.json (nous pouvons changer le nom de la demande).

N ° 14) Nous pouvons voir la liste des demandes effectuées, dans le panneau de gauche sous l'onglet Historique.

#quinze) De plus, nous pouvons enregistrer tous les détails liés à la demande (URI, autorisation, paramètres, corps, etc.) sous une collection existante ou une nouvelle collection. Une fois la demande ajoutée à la collection, nous pouvons l'exporter (la partager) et même importer n'importe quelle collection existante.

Nous pouvons partager la Collection sous forme de lien ou de bibliothèque d'équipe par un simple code généré. Nous pouvons toujours exécuter toute la suite Collection.

Même nous pouvons publier l'URL de la collection sur le Web afin que toute personne accédant à l'URL publiée puisse accéder à la collection et utiliser les services fournis par l'API Web.

Il existe une fonction pour se connecter à POSTMAN, qui nous permet de stocker l'historique, les collections, les données environnementales, le stockage local afin que nous puissions le sauvegarder et y accéder n'importe où, à tout moment après avoir été connecté au POSTMAN.

Coureur

liste de serveurs privés world of warcraft

Il est utilisé pour exécuter les ressources présentes dans le dossier Collections.

Conclusion

La plupart des entreprises adoptent le style architectural REST pour le développement / la mise en œuvre de services Web car il s'agit d'une interface simple et conviviale, qui nécessite moins de formation pour les membres existants / nouveaux du projet. Les organisations envisagent REST avec leurs services Web existants.

Lire aussi = >> Tutoriel sur l'API Flask

Dans le prochain didacticiel de cette série d'API REST, nous aborderons différents types de codes de réponse, types de requêtes REST, etc.

lecture recommandée

• Codes de réponse de l'API Rest et types de demandes de repos
• Tutoriel POSTMAN: Test d'API avec POSTMAN
• Test de l'API REST avec le concombre à l'aide de l'approche BDD
• 10 meilleurs outils de test d'API en 2021 (outils de test d'API SOAP et REST)
• Test de l'API REST avec Spring RestTemplate et TestNG
• Comment automatiser les demandes d'API à l'aide de Rest Assured et Jenkins
• Comment créer un projet REST dans SoapUI Pro: Tutoriel # 13
• Tutoriel Parasoft SOAtest: outil de test d'API sans script