pourquoi ne voyez-vous plus de gens utilisant l'architecture REST pour le système de serveur client. Vous voyez des gens utilisant des sockets, ou TIBCO RV ou EMS ou MQ mais je n'ai pas vu beaucoup d'architecture REST basiqueREST pour la messagerie à faible latence.
quelqu'un sait-il une raison pour laquelle vous éviteriez d'utiliser cette architecture pour la communication client/serveur latence
Je ne pense pas que je l'éviterais nécessairement, mais je peux penser à quelques raisons pour lesquelles je ne pourrais pas le choisir pour un service à haut débit et à faible latence. Tout d'abord, vous devez gérer la totalité de la pile Web pour transmettre votre message à votre service. Cela pourrait introduire un certain nombre de couches et de services inutiles qui retarderaient les messages. Un service personnalisé doit uniquement prendre en charge les couches de protocole requises par le service lui-même. Deuxièmement, à moins que votre service soit le seul service hébergé sur le serveur Web, vous serez en concurrence avec d'autres demandes pour que vos messages soient traités. Même si le fait d'avoir un point de terminaison personnalisé pour votre service peut ne pas résoudre tous les problèmes de contention de ressources, vous n'avez pas à entrer en concurrence pour l'accès des autres services à votre point de terminaison. Troisièmement, un protocole personnalisé doit uniquement prendre en charge les informations de protocole liées au service et peut entraîner des tailles de paquets plus petites car vous n'avez pas besoin de prendre en charge le protocole HTTP supplémentaire. Cela affecterait en particulier les protocoles qui échangent de petits messages car les informations d'en-tête constitueraient une plus grande fraction de la taille du message.
REST ne convient pas à tous les problèmes.
REST est le meilleur pour Gestion des ressources. Si vous écrivez des services Web (comme avec un système client-serveur), vous recherchez des fonctionnalités telles que la représentation des données indépendantes des langages, la validation des arguments, la génération de code client/serveur, la gestion des erreurs et les contrôles d'accès. REST vous oblige fondamentalement à coder ces choses vous-même.
D'un autre côté, il ajoute la couche HTTP. Vous obtenez une intégration transparente des proxies, de la mise en cache, etc., mais vous perdez de la vitesse en raison des en-têtes HTTP, du serveur Web, etc.