Demande d'API externe

Pas trop de théorie ?

Mettons cela en pratique. Ouvrons AppMaster, créons une demande d'API en l'utilisant et comprenons mieux le fonctionnement de cette demande.

Création d'une demande API externe

Les demandes d'API sont créées dans la section "Business logic", dans l'onglet "External API Requests".

Il est temps de cliquer sur "+ New API Request".

Le nom et la description peuvent être définis sur n'importe quoi, ils sont destinés à notre usage personnel uniquement.

Occupons-nous des données qui comptent vraiment.

Le minimum requis pour créer une demande est de spécifier sa Méthode et son adresse (URL). Commençons par la dernière.

URL

URL - Uniform Resource Locator. Une adresse donnée à une ressource particulière sur l'Internet. La version la plus familière d'une telle ressource est une page HTML - nous entrons son URL dans la barre d'adresse du navigateur et ouvrons le site souhaité. En même temps, la ressource elle-même peut être n'importe quoi, une image, une vidéo, un ensemble de données. L'essentiel est que cette ressource possède un pointeur spécifique - une URL à laquelle vous pouvez envoyer une demande pour obtenir cette ressource.

Méthodes

En faisant référence aux données à leur adresse, nous indiquons également la méthode (on peut aussi dire le type) de la demande, c'est-à-dire que nous indiquons ce qui doit être fait avec ces données.

Lorsque nous avons envoyé des requêtes pour la tâche du premier module, nous avons reçu des données. Il s'agit de la méthode GET. Cette méthode est la plus évidente et aussi la seule requise. Par conséquent, même si nous ne l'avons pas spécifié explicitement, il a été supposé par défaut qu'il s'agissait de GET.

Voyons maintenant quelles sont les autres méthodes existantes.

La norme HTTP elle-même ne limite pas le nombre de méthodes qui peuvent être utilisées. En même temps, seules certaines des méthodes les plus standard sont encore utilisées pour maintenir la compatibilité. Il y a 5 méthodes différentes qui peuvent être utilisées dans les requêtes API d'AppMaster.

GET. C'est déjà traité. Cette méthode demande la mise à disposition d'une ressource, et reçoit des données.

POST. Pour prendre des données d'un endroit, vous devez d'abord placer ces données là. C'est ce que fait la méthode POST. Elle envoie des données au serveur et crée une ressource.

PUT. Similaire à la méthode POST, mais son rôle est de mettre à jour les données. Elle ne crée pas de nouvelles données, mais remplace les données existantes, les met à jour.

DELETE. Comme son nom l'indique, cette méthode supprime des données.

PATCH. Cette méthode est similaire à PUT, mais elle est utilisée pour mettre partiellement à jour les données, plutôt que de les remplacer entièrement. Par exemple, en utilisant la méthode PATCH, vous pouvez modifier le titre d'un article ou changer la valeur d'un paramètre.

Il est important de tenir compte du fait que le serveur n'est pas du tout tenu de faire exactement ce qui est spécifié dans la méthode. Nous pouvons envoyer l'adresse d'une certaine page avec la méthode DELETE, mais cela ne signifie pas que le serveur va réellement la supprimer. Mais, de manière purement théorique, il peut le faire avec la commande GET. Ou ne rien modifier, mais en même temps envoyer des données en réponse à POST. Tout simplement parce que le développeur l'a configuré de cette façon.

C'est ici qu'intervient REST, qui dit qu'il est temps de se mettre d'accord sur le respect de la commande, d'arrêter le désordre et de faire exactement ce qui est indiqué dans la méthode. À tout le moins, cela devrait être la tâche principale (mais pas nécessairement la seule). Par exemple, lorsque vous transférez le contenu d'un article en utilisant la méthode GET, vous pouvez en même temps augmenter le compteur du nombre de ses vues de 1.

Nous avons donc compris où se trouvent les données et ce que l'on peut en faire. Allons plus loin, voyons quels autres composants la requête peut avoir.

URL Params

Paramètres de l'URL. Il existe des situations où nous ne connaissons qu'une partie de l'URL. Les articles du site Appmaster.io en sont un exemple. L'adresse de départ de tous les articles est la même : https://appmaster.io/blog/. Mais chaque article a son propre titre et, par conséquent, sa propre partie individuelle pour l'indication exacte de cet article particulier.

Dans une telle situation, on utilise les URL Params. Nous prescrivons immédiatement la partie générale, et laissons le reste à la discrétion du processus. Par conséquent, l'URL est écrite sous la forme https://appmaster.io/blog/:id/.

La partie connue est écrite telle quelle, et la partie variable est placée après le signe " :". Le nom de cette partie variable (déjà sans " :") est ajouté à la liste des paramètres. Dans ce cas, il peut y avoir plusieurs parties variables, et leur emplacement est n'importe où dans l'URL.

Paramètres de requête

Paramètres de requête. Vous vous souvenez que nous avons envoyé une requête à boredapi.com dans le premier module ? Et en plus de l'adresse, des données supplémentaires étaient prescrites. C'était les Query Params.

Ils sont écrits après l'URL et sont séparés de celle-ci par un signe " ?". Le nom du paramètre, le signe "=" et la valeur du paramètre lui-même sont indiqués. Si plusieurs paramètres sont utilisés en même temps, ils sont séparés par le signe "&".

Cependant, lorsque vous spécifiez des paramètres dans AppMaster, vous ne devez pas penser aux règles de requête. Tout sera correctement formaté automatiquement. Il vous suffit de spécifier le nom du paramètre lui-même et de l'ajouter à la liste.

Les Query Params sont utilisés lorsque la source de données est la même, mais que les données elles-mêmes peuvent être différentes. Par exemple, Boredapi contenait une énorme liste de choses à faire. Mais nous n'étions intéressés que par celles qui sont destinées à une seule personne et c'est ce que nous avons spécifié dans les paramètres de la requête.

Un autre cas d'utilisation consiste à limiter la quantité de données. Par exemple, nous pourrions accéder à une certaine liste, mais ne demander que les 5 premières entrées de celle-ci. Cette quantité peut également être un paramètre de requête.

Une autre option est une clé d'accès. Vous avez peut-être utilisé cette option dans le module 1 en vous référant à Alphavantage. Les données ne pouvaient être obtenues qu'après enregistrement et envoi d'une clé personnelle dans les paramètres de requête.

Faites attention aux pages que vous visitez sur Internet, vous y trouverez probablement aussi différents paramètres. Par exemple, si vous ouvrez la page météo de Ventusky.com, dans les paramètres de la requête, les valeurs géographiques de latitude et de longitude sont envoyées.

En-têtes

En-têtes. En-têtes de requête. Les en-têtes contiennent généralement des informations de service sur la demande (méta-informations). Les en-têtes permettent au serveur d'obtenir plus d'informations sur le client qui demande les données. Les en-têtes peuvent contenir des informations sur le navigateur utilisé, l'encodage attendu de la réponse, la langue, l'heure exacte de la demande, etc. Dans le cas d'un accès à des données protégées, les en-têtes peuvent contenir une clé d'autorisation.

Dans la plupart des cas, les en-têtes sont facultatifs. Même dans le premier module, nous avons déjà fait une demande où nous n'avons spécifié aucun en-tête (bien que cela ne signifie pas que la demande a été effectivement envoyée sans eux).

Corps

Corps. Le corps de la requête. Les requêtes GET s'en passent généralement, mais si nous voulons envoyer des données au serveur, envoyer une requête POST ou PUT, alors ces données sont placées dans le corps de la requête. En même temps, vous pouvez placer des données de n'importe quelle complexité dans le corps de la requête, par exemple, envoyer un fichier vidéo, et ne pas être limité à un nombre ou une chaîne de texte.