Discussion :

[Ozim16]

Bonjour,

Dans le cadre d'un projet, nous aimerions avoir un serveur REST et un client. Dans le principe la partie serveur manipule une base de données FireBird et retourne les résultats sous le format JSON au client.
Le client sera à terme multi-plateforme (smartphones essentiellement).
Le tout se fera sous Delphi 10.2 et nous en sommes encore à la phase analyse et conception (tests R&D).
Nous étudions les différentes possibilités offertes par Delphi.
Après des recherches, il apparait que pour la partie serveur notamment, il existe deux possibilités :

- Utiliser DataSnap avec TDSServer et TDSServerClass, en tant que Web Services et mettre à disposition du client des méthodes, qui retourneraient des TFDJSONDataSets ou des TJSONObject
Avec cette méthode, l'encapsulation des données et l'écriture du code est facile à mettre en place, TFDJSONDataSets permettant d'être rempli avec des TFDQuery directement. De plus le contenu des requêtes (réponse JSON) ne transite pas en clair.
C'est la solution que propose des tutoriels Embarcadero (http://docwiki.embarcadero.com/RADSt...ion_et_FireDAC) ainsi qu'en guise d'exemple dans les projets disponibles avec l'installation de Delphi.
Le seul problème serait apparemment la nécessité d'utiliser TFDJSONDataSets pour récupérer les données côté client, de plus, les routes ou accès aux méthodes ne sont plus vraiment REST ('datasnap/rest/TServerMethods/GetTopics' au lieu de GET: 'datasnap/rest/topics')

- La seconde solution avec un WebBroker (Projet Application serveur Web) qui consiste à instantier des TWebActionItems depuis le TWebModule pour chaque route du serveur REST et lui affecter dans la méthode OnAction les fonctions à appeler pour chaque type de requête (GET, POST, PUT...). Néanmoins cela demande générer le JSON "à la main", sans utiliser d'outils comme TFDJSONDataSets qui est plutôt pratique. Côté client, cela se ferait via TRESTClient, TRESTRequest, TRESTResponse.
C'est notamment ce que présente cette vidéo :

(Building RESTful Servers)

Les questions que nous nous posons sont en rapport avec les possibilités qu'offre Delphi pour ce genre de projet, est-ce bien les seules solutions existantes ? quels seraient les avantages/inconvénients des solutions possibles ? en terme de performances, montée en charge, quel est le mieux ?

Merci d'avance pour votre aide.

[GoustiFruit]

Il existe aussi le framework mORMot, qui est probablement le plus performant, mais qui est très pointu techniquement.
La doc générale: https://synopse.info/files/html/Syno...AD%201.18.html
Le forum: https://synopse.info/forum/index.php
Le blog: http://blog.synopse.info/

[alheuredudejeuner]

Bonjour,

WebBroker est très puissant et pas assez connu.

Je le connais dans le cadre d'une grosse appli comme serveur de donnée ntier, et il fonctionne plutôt bien en isapi avec IIS.

Pour le formatage du json, je passerai par une liste d'objet mapper sur les champs de la base de données.
Il y a le problème de passage du datastet à la liste d'objet, relativement aisé dynamiquement avec les RTTI.

Beaucoup d'entre nous se crée des générateur de classe d'objets depuis les champs des tables .

Pour passer de la liste d'objet au Json, l'unité Rest.Json permet de le faire en deux ligne de code.

Pour la réception le peuplement de la liste d'objet est en deux ligne en Delphi.

Les objets Delphi peuvent être copier aisément en java ou .net. Je ne sais pas comment ces langages charges les données json dans les objets, mais j'imagine que ça doit être assez naturel.

Cordialement.

[Ozim16]

Bonjour,

Tout d'abord, merci pour vos réponses.
Nous sommes actuellement en train de tester l'utilisation de mORMot. Du coup une question technique par rapport à ce framework; est-il possible de n'utiliser que la partie REST sans passer par l'ORM intégré ? Nous ne souhaitons pas passer par un ORM mais configurer nous mêmes les routes ainsi que les chemins du serveur REST et utiliser des requêtes via FireDac pour répondre au client. En regardant les exemples de projets fournis avec mORMot, il apparaît qu'il faudrait utiliser TSQLRestServerFullMemory (ou TSQLRestServer) côté serveur en créant un TSQLModel vide pour le serveur. En réalité, ce qui nous parait bizarre c'est la présence de SQL ou DB dans le nom des classes étant donné que l'on souhaite simplement avoir un serveur REST sans ORM.

Après si les réponses et les requêtes transitent en JSON, je ne sais pas s'il sera aisé de convertir notre manière de récupérer les données (via des TFDQuery) en un format facilement traitable par mORMot, en savez-vous davantage à ce sujet ?

Cordialement

[Andry]

Bonsoir,
Regarde aussi du côté de
DMVCFramework de Daniel Teti : https://github.com/danieleteti/delphimvcframework
Mars Curiosity de Andrea Magni :https://github.com/andrea-magni/MARS
Cordialement
Andry