Editions ENI Livres | Vidéos | e-Formations
Serveur d’application REST
Définition : application distribuée
Une application distribuée, aussi appelée application N-Tiers, signifie qu’elle nécessite plusieurs plateformes pour s’exécuter complètement. L’architecture des applications internet est dans sa très grande majorité distribuée. On a en général une partie de l’application, nommée le Frontend, qui s’exécute sur le poste de l’utilisateur soit à travers un navigateur, soit à travers un client lourd Windows ou mobile (Android ou iOS). Cette application communique par TCP/IP en général (ou UDP) avec la partie Backend de l’application. C’est dans la partie Backend que l’on retrouve les règles métiers et la persistance des données.
Si on reprend le design pattern MVC, on retrouve la vue V dans le Frontend et la partie Controler C dans le Backend. Les modèles M sont échangés entre le Frontend et le Backend par un protocole de communication. En général, on utilise le protocole HTTP ou HTTPS (HTTP sécurisé) pour communiquer entre le client et le serveur.
Protocole HTTP
HTTP, pour Hypertext Transfer Protocol, est un protocole de communication client-serveur standardisé par l’IETF (Internet Engineering Task Force). Il est pleinement utilisé sur l’Internet actuel. Il utilise le protocole de transport TCP de communication réseau. Sa variante sécurisée est connue sous le nom de HTTPS. En général, le protocole HTTP utilise le port 80 et HTTPS le port 443.
La communication entre le client et le serveur est monodirectionelle. C’est toujours le client qui fait une requête et le serveur qui répond. Le serveur n’initie jamais une communication avec le client.
Ce protocole fournit un ensemble de commandes dont voici la liste :
-
GET : méthode utilisée pour demander une ressource (page HTML ou image par exemple).
-
HEAD : méthode qui demande des informations sur une ressource du serveur.
-
POST : méthode qui est utilisée pour transmettre des informations du client vers le serveur, comme par exemple un enregistrement de données (enregistrement d’un utilisateur).
-
OPTIONS : méthode pour obtenir les options de communication.
-
CONNECT : méthode pour utiliser un proxy comme tunnel de communication.
-
TRACE : méthode qui demande au serveur de retourner les informations qu’il a reçues. Elle est utilisée pour effectuer un diagnostic de l’application....
Exemple d’échanges de données : information de météo
Prenons par exemple le cas d’un utilisateur qui souhaite savoir quel temps il fait dans une ville à une certaine date. En général, l’utilisateur utilise son navigateur et se connecte à l’application hébergée à l’URL (application fictive) www.whatismyweather.com. Il accède rapidement à un formulaire pour saisir deux paramètres ville et date.
Nous allons examiner les méthodes les plus courantes pour faire transiter ces paramètres au serveur.
1. Par le protocole HTTP
On utilise dans ce cas la méthode GET : elle permet de faire transiter les paramètres directement dans l’URL. Les paramètres apparaissent en clair dans la barre d’adresse du navigateur. Quand il s’agit de données sensibles comme des identifiants ou des numéros de cartes bancaires, cette méthode est à éviter absolument. Dans le cas d’une demande d’information météo, cela n’est pas gênant.
Prenons ainsi comme exemple l’URL suivante:
http:// www.whatismyweather.com/getweather.html?
city=Paris&date=20201201 -
L’URL se découpe dans ce cas en deux morceaux par le caractère ?. L’URL à proprement parler est à gauche du ? et l’ensemble des paramètres à droite.
-
Le caractère & sépare le jeu de clé/valeur pour chaque paramètre.
-
Le caractère = est le séparateur pour chaque couple clé/valeur.
Ainsi, on reconnaît deux jeux de paramètres : city=Paris et date=20201201.
Il est également possible d’utiliser la méthode POST : les paramètres ne sont plus en clair, mais dans le corps de la requête HTTP.
L’URL ainsi appelée serait dans ce cas :
http://www.whatismyweather.com/getweather.html Cette écriture d’URL combine un affichage plus esthétique d’une part, tout en garantissant une meilleure sécurité d’autre part. Cependant, concernant des données sensibles, il faudra procéder au chiffrement des trames HTTP en passant sur le protocole HTTPS.
2. Par le protocole SOAP (Simple Object Access Protocol)...
Service web et web-méthodes REST
1. Cas général
Un service web est un programme accessible grâce à Internet. Il exploite un protocole de communication Internet qui est le plus souvent HTTP (mais l’utilisation de SMTP ou de FTP est théoriquement également possible) en utilisant un formalisme connu XML ou JSON. Ce service web expose une liste de fonctionnalités qui, unitairement, sont appelées des web méthodes.
Un service web se veut toujours interopérable, c’est-à-dire qu’un client qui exploite le service web peut ne pas fonctionner sur le même type de plateforme et ne pas être implémenté dans le même langage de programmation que le service web. Cette interopérabilité est assurée par l’utilisation d’un protocole indépendant (HTTP) conjointement à un formalisme standardisé (XML/JSON).
Dans le cas de REST, le protocole à utiliser est HTTP, le formalisme peut être tout aussi bien XML ou JSON.
En reprenant l’application de e-commerce que l’on souhaite réaliser, on peut donc définir cinq web méthodes comme ci-dessous :
-
Enregistrement d’un utilisateur :
POST www.myecommerce.fr/users -
Authentification d’un utilisateur
Le cas de l’authentification est plus complexe que les autres, il sera étudié en détail dans la section suivante.
-
Mise à jour d’un utilisateur :
PUT www.myecommerce.fr/users Les paramètres seront passés au format JSON dans le corps de la requête.
HTTP :
-
Récupération des objets à acheter :
GET www.myecommerce.fr/items -
Validation de la commande :
POST www.myecommerce.fr/purchases Par rapport à ce qu’on peut trouver sur un site de e-commerce standard, il n’y a aucune gestion de panier côté serveur. On pourrait très bien en ajouter une afin de gérer une sauvegarde du panier en cours par exemple.
2. Cas de l’authentification
a. La problématique
Dans de nombreuses applications Internet, il est nécessaire de s’authentifier pour pouvoir accéder à une partie ou à l’intégralité des services proposés par l’application.
Le cas d’application suppose qu’un utilisateur s’authentifie...
Implémentation de l’application côté serveur
Le but de cette section est de concevoir un service web répondant aux spécifications REST. Le cas d’application reste l’application d’achat d’objets conçue au chapitre Utilisation du design pattern MVC. Les "services" permettant l’utilisation de l’application comme le login, l’enregistrement d’un utilisateur, le choix d’objet ou la validation de panier vont être extraits de l’application et être hébergés dans un serveur d’application web Apache.
Concrètement, en reprenant l’implémentation faite au chapitre Utilisation du design pattern MVC, le code des contrôleurs et des modèles va être inclus dans le module Apache que l’on va développer avec très peu de modification. Là encore réside l’intérêt du design pattern MVC, vu dans le chapitre précédemment cité, qui permet de découpler aisément la partie visualisation de la partie métier.
1. Le projet Web Server Application
Delphi propose deux modèles de projet pour implémenter des web services. Ils se situent dans la section Web de l’assistant. Pour faire apparaître l’assistant, il faut sélectionner dans le menu Files : Files - New - Other. L’écran ci-dessous apparaît :
Sur la deuxième page du wizard de création de projet, choisissons Windows (une implémentation est possible par ailleurs pour Linux avec la version Entreprise en utilisant exclusivement la RTL et les unités FireMonkey) :
Sélectionnons ensuite parmi tous les types de projet Apache dynamic link module :
Les projets Stand-alone console application (ou également Stand-alone GUI application) encapsulent un composant Indy HttpServer qui se comporte à peu près pareil que le composant Indy TCPServer étudié pendant l’élaboration d’une application de messagerie instantanée au chapitre Communication interprocessus (IPC). Cependant, il est encapsulé dans la couche applicative TWebApplication et par conséquent son comportement devient similaire à celui choisi pour un projet de type apache module.
Les deux autres types de projets font...
Conclusion
Les règles essentielles pour créer un serveur web répondant aux spécifications REST ont été vues. Il en existe beaucoup d’autres. L’utilisation du design pattern MVC lors du précédent développement a grandement facilité la migration d’une application de type lourde à celle de type N-Tiers. Le code source a pu être réutilisé sans modification, ce qui montre l’intérêt de suivre un tel motif de conception.
La problématique de l’authentification a été étudiée dans le détail. Les concepts mis en jeux sont d’ordres généraux et, qu’il s’agisse de développer en Delphi, Java ou C#, il est nécessaire de bien les comprendre pour éviter les problèmes de sécurité ou d’applications mal conçues qui conduisent à de grandes difficultés de maintenance.
Des Frameworks présents sur le marché ou en open source peuvent accélérer le développement de serveur d’application REST. Cependant, il est nécessaire de bien comprendre tous les concepts sous-jacents pour utiliser ces Frameworks correctement.