REST pour la messagerie à faible latence.

Question

Pourquoi ne voyez-vous pas plus de personnes utiliser l'architecture REST pour le système client-serveur? Vous voyez des gens utiliser des sockets, TIBCO RV, EMS ou MQ mais je n’ai pas vu beaucoup d’architecture REST de base

Quelqu'un sait-il pourquoi vous évitez d'utiliser cette architecture pour la communication client / serveur avec une latence élevée / basse

Answer 1

Je ne sais pas si je l'éviterais nécessairement, mais je peux penser à deux raisons pour lesquelles je ne pourrais pas le choisir pour un service à haut débit et à faible temps de latence. Tout d’abord, vous devez gérer l’ensemble 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 ne soit le seul à être hébergé sur le serveur Web, vous serez en concurrence avec d'autres demandes de traitement de vos messages. Même si un point de terminaison personnalisé pour votre service peut ne pas résoudre tous les problèmes de conflit de ressources, vous n'avez au moins pas à faire concurrence pour obtenir l'accès d'autres services à votre point de terminaison.

Troisièmement, un protocole personnalisé doit uniquement prendre en charge les informations de protocole relatives au service et peut entraîner une réduction de la taille des paquets car il n'est pas nécessaire de prendre en charge la surcharge de protocole HTTP supplémentaire. Cela affecterait particulièrement les protocoles qui échangent de petits messages, car les informations d’en-tête ne représentent qu'une fraction plus grande de la taille du message.

Answer 2

REST ne convient pas à tous les problèmes.

REST est préférable pour la gestion de Ressources . Si vous écrivez des services Web (comme avec un système client-serveur), vous constaterez que vous souhaitez des fonctionnalités telles que la représentation de données indépendante de la langue, la validation des arguments, la génération de code client / serveur, la gestion des erreurs et les contrôles d'accès. REST nécessite essentiellement que vous codiez ces choses vous-même.

D'autre part, il ajoute la couche HTTP. Vous obtenez une intégration transparente des proxies, de la mise en cache, etc., mais vous perdez un peu de vitesse à cause des en-têtes HTTP, de l’interface du serveur Web, etc.