Test d’API avec POSTMAN | AU NOUVEAU Blog

Qu’est-ce que l’API ?

Une API est une interface ou un protocole de communication entre un client et un serveur qui vise à simplifier l’application côté client pour une meilleure expérience utilisateur.

Qu’est-ce qu’un Reposant API ?

Les API RESTful suivent l’architecture REST (Concernantprésentation Stat Jtransfert).

# Qu’est-ce que l’URI pour l’URL du point de terminaison ?

Fondamentalement, l’API/l’URL du point de terminaison est la combinaison d’éléments comme ci-dessous : {Base URL} + {Resource} + {Path/Query Parameter}

Paramètre de chemin : Les paramètres de chemin sont différentes parties de l’URL du point de terminaison. Ils sont utilisés pour pointer vers une ressource spécifique au sein de la collection. Disons qu’un utilisateur peut être reconnu par ID.
Exemple : https://www.google.com/images/234123 <—– Paramètre de chemin

Paramètre de requête : Une requête Le paramètre est utilisé pour trier/filtrer les ressources. Paramètre de requête identifié par un point d’interrogation « ? »
https://www.google.com/search?q=newyork

Ressources:

Les ressources représentent l’API/Collection, accessible depuis le serveur.

Par exemple: google.com/maps

google.com/search

google.com/images

Vous pouvez voir quelques informations de base pour effectuer des tests d’API. Fondamentalement, c’est une architecture client-serveur. Le client envoie la demande au serveur et le serveur renvoie la réponse. Vous pouvez voir quelques informations ci-dessous :

Méthodes de test d’API

Obtenir la méthode : Lorsque nous voulons récupérer les données du serveur, nous utilisons la méthode GET pour récupérer les données.

Méthode POST : Lorsque nous voulons créer une nouvelle ressource sur le serveur, nous utilisons la méthode POST.

Méthode PUT : Lorsque nous voulons mettre à jour une ressource existante, nous utilisons la méthode PUT pour la modifier. Si le paramètre que nous voulons mettre à jour est disponible, alors il modifie ce paramètre. Si ce paramètre n’est pas disponible, il crée ce paramètre.

Méthode PATCH : Lorsque nous voulons faire une mise à jour partielle, nous utilisons la méthode PATCH pour mettre à jour. Nous ne transmettons que le paramètre que nous voulons mettre à jour, nous n’avons pas besoin de transmettre une charge utile complète pour mettre à jour la ressource.

Codes de réponse

1xx réponse informative – la demande a été reçue, poursuite du processus

2xx réussi – la demande a été reçue, comprise et acceptée avec succès

200 OK : La réponse réelle dépendra de la méthode de requête utilisée. La réponse contiendra une entité correspondant à la ressource demandée dans une requête GET.

201 créé : La demande a été satisfaite, ce qui a entraîné la création d’une nouvelle ressource.

202 Accepté : La demande a été acceptée pour traitement mais n’a pas été complétée.

redirection 3xx – d’autres mesures doivent être prises afin de compléter la demande erreur client 4xx – la requête contient une mauvaise syntaxe ou ne peut pas être satisfaite.

400 Requête incorrecte : Le serveur ne peut pas ou ne veut pas traiter la demande en raison d’une erreur apparente du client (par exemple, syntaxe de demande mal formée, taille trop grande, cadrage de message de demande invalide ou routage de demande trompeur).

401 Non autorisé : Semblable à 403 Forbidden, mais spécifiquement pour une utilisation lorsque l’authentification est requise et a échoué ou n’a pas encore été fournie.

403 Interdit : La demande contenait des données valides et a été comprise par le serveur, mais le serveur refuse d’agir. Cela peut être dû au fait que l’utilisateur ne dispose pas des autorisations nécessaires pour une ressource.

404 Non trouvé : La ressource demandée est introuvable mais peut être disponible à l’avenir.

Erreur de serveur 5xx : TLe serveur n’a pas réussi à répondre à une demande apparemment valide.

500 Erreur interne du serveur : Un message d’erreur générique, donné lorsqu’une condition inattendue est rencontrée et qu’aucun message plus spécifique ne convient.

501 Non mis en œuvre : Le serveur ne reconnaît pas la méthode de demande ou n’a pas la capacité de répondre à la demande. Habituellement, cela implique une disponibilité future (par exemple, une nouvelle fonctionnalité d’une API de service Web).

502 Mauvaise passerelle: Le serveur agissait en tant que passerelle ou proxy et a reçu une réponse non valide du serveur en amont.

503 Service Indisponible: Le serveur ne peut pas traiter la requête (car il est surchargé ou arrêté pour maintenance). Généralement, il s’agit d’un état temporaire.

504 portail expiré: Le serveur agissait en tant que passerelle ou proxy et n’a pas reçu de réponse rapide du serveur en amont.

Quelles sont toutes les validations effectuées lors de l’exécution des tests d’API ?

Code d’état: – Il valide si l’API renvoie le code d’état correct ou non. Le code d’état 201 doit être remplacé lors de la création d’une ressource, 400 pour les mauvaises demandes, 500 pour une erreur interne du serveur, 401 pour un accès non autorisé, etc.

JSON Schéma: – si nous travaillons avec rassurez-vous, donc selon la logique métier, nous devons parfois valider si ce schéma JSON est correct ou non.

Messages d’erreur: – En cas de scénario négatif, nous devrions obtenir des messages d’erreur appropriés avec un code d’erreur comme 400 en cas de mauvaise demande.

Réponse: – Dans le cas d’un chemin heureux (scénarios positifs), nous validons la réponse que les valeurs de réponse sont des valeurs attendues ou non.

Entête: – Nous pouvons également valider les en-têtes, mais cela dépend de l’exigence.

Temps de réponse: – Nous pouvons valider le temps de réponse de l’API. Le temps de réponse est le temps qui est pris par le serveur pour valider les demandes d’API, puis fournir des réponses en retour.

Différence entre HTTP et HTTP : HTTP signifie Hypertext Transfer Protocol,
un protocole et une syntaxe pour présenter des informations – utilisé pour transférer des données sur un réseau. La plupart des informations envoyées sur Internet, y compris le contenu du site Web et les appels d’API, utilisent le protocole HTTP.

Le S dans HTTPS signifie « sécurisé ». HTTPS utilise TLS (ou SSL) pour chiffrer les requêtes et les réponses HTTP, donc dans l’exemple ci-dessus, au lieu du texte, un attaquant verrait un tas de caractères apparemment aléatoires.

« Si un site Web utilise HTTP au lieu de HTTPS, toutes les requêtes et réponses peuvent être lues par toute personne qui surveille la session. Essentiellement, un acteur malveillant peut simplement lire le texte de la demande ou de la réponse et savoir exactement quelles informations quelqu’un demande, envoie ou reçoit.

TROUVÉ CELA UTILE ? PARTAGEZ-LE