REST für Messaging mit geringer Latenz.

Question

Warum sieht man nicht mehr Leute, die die REST-Architektur für Client-Server-Systeme verwenden? Man sieht Leute, die Sockets, oder TIBCO RV oder EMS oder MQ verwenden, aber ich habe nicht viel von der grundlegenden REST-Architektur gesehen.

Weiß jemand einen Grund, warum man diese Architektur für die Kommunikation zwischen Client und Server bei hoher Durchsatz/geringer Latenz vermeiden würde?

Answer 1

REST ist nicht für jedes Problem geeignet.

REST ist am besten für die Verwaltung von Ressourcen geeignet. Wenn Sie Webdienste schreiben (wie bei einem Client-Server-System), werden Sie feststellen, dass Sie Dinge wie sprachunabhängige Daten darstellung, Argumentvalidierung, Client/Server-Code-Generierung, Fehlerbehandlung und Zugriffskontrollen benötigen. REST erfordert im Grunde genommen, dass Sie diese Dinge selbst codieren.

Andererseits fügt es die HTTP-Ebene hinzu. Sie erhalten nahtlose Integration von Proxies, Caching usw., aber Sie verlieren aufgrund von HTTP-Headern, dem Webserver-Frontend usw. etwas an Geschwindigkeit.

Answer 2

Ich weiß nicht, ob ich es unbedingt vermeiden würde, aber ich kann mir ein paar Gründe vorstellen, warum ich es vielleicht nicht für einen High-Throughput-, Low-Latency-Service wählen würde. Erstens muss man sich mit dem gesamten Web-Stack befassen, um seine Nachricht an den Service zu übermitteln. Dies könnte eine Reihe unnötiger Ebenen und Dienste einführen, die Nachrichten verzögern würden. Ein benutzerdefinierter Dienst muss nur die Protokollschichten unterstützen, die vom Dienst selbst benötigt werden.

Zweitens, es sei denn, Ihr Dienst ist der einzige Dienst, der auf dem Web-Server gehostet wird, konkurrieren Sie mit anderen Anfragen um die Bedienung Ihrer Nachrichten. Auch wenn ein benutzerdefinierter Endpunkt für Ihren Dienst nicht alle Ressourcenkonflikte lösen mag, müssen Sie zumindest nicht mit anderen Diensten um den Zugriff auf Ihren Endpunkt konkurrieren.

Drittens muss ein benutzerdefiniertes Protokoll nur die tatsächlichen dienstbezogenen Protokollinformationen unterstützen und kann zu kleineren Paketgrößen führen, da Sie die zusätzliche HTTP-Protokollüberlastung nicht unterstützen müssen. Dies würde insbesondere Protokolle beeinflussen, die kleine Nachrichten austauschen, da die Header-Informationen einen größeren Anteil an der Nachrichtengröße darstellen würden.