Le premier module s'est terminé par la création d'une requête HTTP, son envoi et l'obtention d'une réponse.

Nous le ferons encore de nombreuses fois à l'avenir. Nous enverrons des requêtes à des serveurs tiers. Nous créerons des applications qui accepteront elles-mêmes ces demandes et renverront une réponse. Nous créerons une logique complexe pour traiter les demandes.

Par conséquent, il serait bon d'étudier en profondeur tout ce qui concerne ces demandes, de les analyser en détail. Ainsi, vous ne vous contenterez pas de copier la demande quelque part et de la répéter, mais vous comprendrez vraiment comment tout cela fonctionne.

C'est ce que nous ferons dans le deuxième module. C'est parti !

Commençons par la théorie.


Apprendre l'API REST

Les bases de l'API REST

Si vous avez fait vos devoirs dans le premier module et étudié la documentation, vous avez dû remarquer l'acronyme API. En fait, c'est la documentation API qui est la première chose que les développeurs doivent étudier s'ils veulent comprendre l'interaction avec un service ou une application sur le réseau.

API - Application Programming Interface. Il s'agit d'une description des moyens par lesquels le client et le serveur peuvent communiquer entre eux. Nous ouvrons la documentation de l'API et apprenons à partir de là comment obtenir les données nécessaires du serveur.

Nous voulons toujours que cette interaction soit simple et compréhensible. Cela simplifie la tâche à la fois des développeurs (pas besoin de réinventer la roue lors de la conception d'un nouveau service) et des utilisateurs (un service est beaucoup plus facile à apprendre s'il fonctionne sur le même principe que les services déjà connus). Il convient ici de rappeler un nouveau terme : REST.

REST - acronyme de Representational State Transfer. Cela peut ne pas sembler très clair, mais pour faire simple, REST est un style d'interaction (échange d'informations) entre un client et un serveur.

Il ne s'agit pas d'un ensemble rigide de règles et d'exigences. REST ne force pas l'utilisation d'un langage de programmation particulier et ne lie pas les mains à des directives strictes. REST est appelé un style architectural et il définit 6 principes auxquels l'architecture d'un système doit se conformer.

En conséquence, une API développée en tenant compte des principes de REST est appelée une API REST, et les applications elles-mêmes sont appelées RESTful.

Nous allons créer de telles applications RESTful, il est donc intéressant de discuter dès maintenant des principes auxquels elles se conformeront.

  1. Modèle client-serveur. Ce principe définit la séparation du client et du serveur, la différenciation de leurs besoins. Le client n'a pas à se soucier de la manière dont les données sont stockées, l'essentiel est qu'elles soient délivrées sur demande. De son côté, le serveur ne se soucie pas de ce que le client fera de ces données, de la manière dont il les traitera et les affichera. Cela leur permet de se développer indépendamment l'un de l'autre et améliore l'évolutivité du système.
  2. Aptitude à l'état. Ce principe signifie que le serveur ne doit pas "penser" la réponse en fonction de l'expérience antérieure avec ce client. Toute demande est faite de telle sorte qu'elle contient toutes les informations nécessaires à son traitement, indépendamment des demandes précédentes.
  3. Mise en cache. Pour minimiser les données transmises, il existe un mécanisme de mise en cache. Par exemple, si un logo est affiché sur une page, il est inutile de le demander au serveur à chaque fois. Il ne change pas si souvent, il suffira de le récupérer une fois et de le sauvegarder sur l'ordinateur du client, dans le cache. Mais si nous avons besoin d'obtenir des informations sur la vitesse actuelle de la voiture, le cache ne sera d'aucune utilité. Ce principe détermine que les données transmises par le serveur doivent être désignées comme pouvant être mises en cache ou non.
  4. Interface uniforme. Ce principe définit un format unique d'interaction client-serveur. La structure de toutes les demandes doit être la même. Les données doivent être envoyées sous la même forme, quelle que soit la personne qui les demande.
  5. Système en couches. Le client et le serveur ne communiquent pas nécessairement directement. La transmission des données peut passer par plusieurs nœuds intermédiaires. Dans ce cas, le système est conçu de manière à ce que ni le client ni le serveur ne sachent s'ils interagissent avec l'application finale ou avec un nœud intermédiaire. Cela permet d'équilibrer la charge sur les serveurs, d'augmenter l'évolutivité.
  6. Code à la demande (facultatif). Le seul principe qui n'est pas obligatoire. Selon ce principe, le client peut étendre ses fonctionnalités en téléchargeant du code exécutable depuis le serveur (par exemple, des scripts). Dans ce cas, le code ne doit être exécuté que sur demande.

Pas trop de théorie ?

Mettons cela en pratique.

Création d'une requête API

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


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 comme bon vous semble, 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 - 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.

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 les y placer. 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 changer 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 là 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.


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/en/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/ru/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. 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 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 étaient destinées à une seule personne, et c'est ce que nous avons indiqué dans les paramètres 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 la demande.

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 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é, le codage 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. 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.

La réponse qui provient du serveur fonctionne presque selon le même schéma. Pour des raisons évidentes, elle n'a pas de paramètres de demande, mais les en-têtes et le corps sont inclus dans la réponse (même s'ils peuvent être vides).

Une différence importante est le statut de la réponse.

Lecode d'état. Il figure sur la première ligne de la réponse du serveur. Le statut est un nombre à trois chiffres (le code lui-même), suivi d'une phrase l'expliquant.

C'est par le code d'état que vous pouvez connaître les résultats de la demande et comprendre quelles actions doivent être entreprises ensuite.

Tous les codes d'état possibles sont répartis en 5 classes. Le premier chiffre du code détermine l'appartenance à une classe particulière. Décomposons-les.

1xx - codes d'information. Ils signalent l'état d'avancement de la demande. Dans la pratique, ils sont rarement utilisés.

2xx - codes de réussite. Ils signalent que tout est en ordre et que la demande a été exécutée avec succès. En réponse à une demande GET, nous nous attendons généralement à recevoir un code 200 (OK). Une demande PUT réussie envoie un code 201 (Created).

3xx - redirections. Indique que la demande doit être envoyée à une autre adresse. Le code 301 (Moved Permanently), par exemple, indique que les données requises se trouvent désormais à une nouvelle adresse (la nouvelle adresse elle-même est transmise dans l'en-tête Location).

4xx - codes d'erreur du client. Le plus connu d'entre eux - 404 (Not Found), signale qu'il n'y a pas de données nécessaires à l'adresse spécifiée. Autres cas courants : 400 (Bad Request, erreur de syntaxe dans la demande), 401 (Unauthorized, authentification requise pour l'accès), 403 (Forbidden, accès refusé).

5xx - codes d'erreur du serveur. Signale une erreur du côté du serveur. Par exemple : 500 (Internal Server Error, toute erreur incompréhensible qui ne peut être attribuée à un code connu), 503 (Service Unavailable, le serveur est temporairement incapable de traiter la demande pour des raisons techniques).

À ce stade, nous pouvons supposer que nous avons traité les informations de base pour comprendre l'API REST et la structure des demandes et réponses HTTP. Il ne reste plus qu'à clarifier un seul point : les types de données. Si vous avez déjà essayé de créer votre demande API dans AppMaster, vous avez probablement remarqué que toutes les données (dans les paramètres, dans les en-têtes, dans le corps) vous demande de spécifier non seulement le nom, mais aussi le type de données.


Il est généralement assez évident pour un humain comment travailler avec les données, car il y a un certain contexte. Supposons que nous sachions que 2 + 2 = 4. Nous supposons qu'il s'agit de nombres et que le résultat de l'addition sera un autre nombre.

Mais il se peut qu'il ne s'agisse pas de nombres, mais de données textuelles. Alors le résultat de leur addition pourrait être la concaténation de chaînes de caractères et 2 + 2 se transformerait en "22". Ici, pour que l'ordinateur n'ait pas à penser à quoi que ce soit, il y a une indication exacte du type de données. Et en même temps, d'autres tâches sont résolues. Par exemple, une protection est assurée contre la saisie de données incorrectes ; initialement, il n'est pas possible d'enregistrer une adresse électronique dans le champ destiné à la saisie des chiffres d'un numéro de téléphone.

Il existe un grand nombre de types de données différents, nous allons maintenant considérer les plus basiques, et dans les modules suivants du cours, nous nous familiariserons avec les autres.

String - Type de données String, texte brut sans formatage spécial.

Integer - Type de données Integer. Peut être utilisé pour les compteurs ou les calculs où les nombres fractionnaires ne sont pas nécessaires.

Float - Nombre à virgule flottante. Il est utilisé lorsqu'une précision accrue est nécessaire et que les valeurs entières ne suffisent pas.

Une question logique peut se poser ici. Pourquoi ne pas toujours utiliser Float, pourquoi avons-nous besoin d'Integer alors ? Mais une plus grande précision nécessite plus de ressources. Pour certains petits calculs, cela peut être totalement invisible, mais dans le cas de grandes quantités de données, l'utilisation d'un type de données raisonnable peut réduire considérablement les besoins en puissance de calcul et en espace disque.

Booléen - type de données booléen. Le type de données le plus simple. Il prend l'une des deux valeurs suivantes, qui s'écrivent comme Vrai ou Faux. Vous pouvez souvent voir la désignation sous la forme de 1 (vrai) et 0 (faux).


Devoirs à domicile

Reprenez les requêtes du devoir au premier module en les créant dans AppMaster dans la section External API Requests.

  1. Créez une requête à BoredAPI. Spécifiez au moins 5 paramètres différents de la documentation. Soumettez plusieurs requêtes différentes, en spécifiant uniquement les paramètres requis.
  2. Créez une requête à Alphavantage. Utilisez les paramètres pour obtenir les taux de différentes devises les unes par rapport aux autres.