Discussion :

[Anselme45]

Bonjour,

En l'état normal, une app envoie vers un serveur une requête REST et reçoit en retour une réponse à la requête.

Mais que se passe-t-il, si l'app client envoie dans un laps de temps très court de nombreuses requêtes REST et surtout envoie des nouvelles requêtes REST alors que le serveur n'a pas encore répondu aux précédentes requêtes?

Est-ce que cela fonctionne avec un système du genre tampon?

Est-ce que les nouvelles requêtes sont envoyées une à une seulement quand la requête REST précédente à reçu une réponse?

Est-ce que toutes les requêtes sont envoyées au serveur et l'app client récupère les réponses dans l'ordre dans laquelle le serveur répond?

[ShaiLeTroll]

Cela dépend de ta bibliothèque mais aussi de la logique de ton api REST, est-ce que lib synchrone ou pas.

Si synchrone, le problème ne se pose pas, tu fais ton appel, la lib attend la réponse, tu es obligé de faire toi-même plusieurs threads donc tu gères toi même la parallélisation et au beosin l'ordonnancement et les dépendances de résultats.

Si asynchrone, l'ordre de retour peut varier, dans le désordre c'est possible, mais tu as des objets de context qui permet de savoir à quoi correspond la réponse, c'est plutôt rare en Delphi d'ailleurs on voit ça plus dans les langages JavaScript qui sont conçus pour ces problématiques REST à coup d'infame async await et si il y a des appels relatifs, lié par un résultat d'un appel qui s'utilise comme paramètre de l'appel suivant, évidemment que le code sera écrit pour que cela reste séquentiel.

Ce n'est pas le client qui gère ça, il "subit" le fonctionnement du serveur.


REST c'est du HTTP donc par définition, un mode déconnecté et potentiellement state-less.

Si il n'y a pas d'ordre logique métier dans les appels, ton serveur REST DOIT encaisser plusieurs requêtes en simultanées et concurrentielles.
ET encore une fois, la réponse ne peut pas être prédit, avant les serveurs REST étaient multi-threads, mais cette mode disparaît avec un traitement séquentiel par le serveur c'est le répartiteur de charge à l'instar NGINX couplé à Kubernetes qui va gérer l'utilisation de 1 à n worker qui iront dépiler les requêtes, le code du serveur étant plus simple, et au final plus performant car la logique de répartitions est mieux gérée ailleurs.

Pense que HTTP est basé sur TCP/IP, déjà ce dernier fourni un tampon des données reçues, les serveurs HTTP gèrent très bien ça, si l'on prend ça à la façon Delphi, souvent à base de Indy (faudrait regarder aussi DataSnap) mais cela lance des threads (en pool ou non) et cela dépile les messages un par un, évidemment qu'une requête facile à traiter sera retournée plus vite qu'une requête longue, donc par définition c'est traiter dans l'ordre mais selon la complexité cela peut créer du désordre, le client normalement surtout en Delphi, il est bloquant donc il attend sa réponse, à toi de gérer les threads.


La bonne question à te poser c'est "Est-ce que la logique métier requiert un ordonnancement"

[Anselme45]

Merci pour tes éclaircissements.

Côté Delphi, les échanges REST sont traités à l'aide de la chaine de composants TRESTClient, TRESTRequest, TRESTResponse, TRESTResponseDataSetAdapter. Côté serveur REST, il s'agit d'un service externe et nous ne disposons pas de détails sur son mode de fonctionnement.

Je vais faire des tests pour évaluer le comportement du serveur REST et si nécessaire, je vais utiliser les threads.