Théorie des API REST

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 !

Théorie générale

Commençons par la théorie.

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

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

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 n'impose 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 à présent des principes auxquels elles devront se conformer.

Principes RESTful

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 étant 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.

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.

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.

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.

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é.

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 doit être exécuté uniquement à la demande.