Verwenden von blockierenden REST-Anforderungen zum Implementieren von Publish/Subscribe

Question

Ich wurde kürzlich gebeten, die Machbarkeit der Integration mit einem Telefonsystemanbieter zu untersuchen, der Telefonereignisse (z. B. Leitung klingeln, Nebenstelle beantwortet, Anruf gelöscht) mit RESTful verfügbar machen möchte Internetservice.

Ich wies darauf hin, dass REST ein Anfrage/Antwort-Protokoll ist und sie publizieren/abonnieren. Die Lösung, die sie vorschlugen, bestand darin, eine HTTP-REST-Anforderung zu stellen, die blockierte und dann schließlich reagierte, wenn und wann ein Ereignis verfügbar war - oder eine Zeitüberschreitung.

In jedem Fall würde eine andere Anfrage gemacht werden, um das nächste Ereignis und so weiter ad infinitum zu bekommen.

Diese Idee ließ mich zusammenzucken, aber mir wurde versichert, dass das iPhone "Push" E-Mail auf diese Weise funktioniert.

Ist das eine vernünftige Verwendung von REST?

Answer 1

Ich würde sagen, dass es nicht gut mit dem REST-Architekturstil fliegt (hauptsächlich, weil REST es auf statusfreie Client-Server-Interaktionen einschränkt). Das Internet ist jedoch reich an Lösungen, die lange Abfragen durchführen, und es funktioniert mehr oder weniger, obwohl es nicht im Sinne des Internets ist.

Zunächst eine Anmerkung zur Architektur: Das Implementieren von Pub/Sub innerhalb von REST bedeutet lediglich, dass der Herausgeber Elemente zu einer Liste hinzufügt, die dann für die Abonnenten verfügbar gemacht wird. Abonnenten fragen die Liste ab. Es gibt Möglichkeiten, dies herzustellen, um einmal und nur einmal zu gewährleisten, während die Nachrichtenreihenfolge und (eine Form der) garantierten Zustellung beibehalten wird, wenn auch asynchron. Es skaliert wirklich gut und ist wirklich belastbar.

Mein erster Ratschlag wäre, es optional zu machen, so dass Clients, die nicht lange Abfragen durchführen können (oder nicht wollen), dies tun können. Ich würde sogar so weit gehen zu sagen, dass, wenn ein generischer Client (wie Google) der Standard wäre nicht lange Abfrage durchführen, und dass der Server die lange Polling in einem speziellen gemeinsamen Verständnis zwischen Ihrem Client und der Server. Dieses gemeinsame Verständnis könnte ein benutzerdefinierter Medientyp oder eine benutzerdefinierte Link-Beziehung oder sogar ein benutzerdefinierter HTTP-Header sein, von dem generische Clients nichts wissen würden. Clients, die Ihre lange Umfrage unterstützen, werden auf codiert. Entdecken Sie die Funktionen der langen Abfrage, und rufen Sie sie bei Bedarf auf, wenn die lange Abfrage fehlschlägt (z. B. ein Intermediär blockiert sie irgendwie).

Und anstatt dies über HTTP zu tun, würde ich empfehlen, einen Nicht-HTTP-Socket dafür zu verwenden, um nicht die Absichten von HTTP zu verletzen und effektiv HTTP als Transportprotokoll zu verwenden. Siehe Kometd.

Mein anderer Ratschlag wäre, die Frage zu stellen, wie "Echtzeit" Ihre Kunden sein müssen. Wenn eine Latenzzeit von wenigen Sekunden akzeptabel ist, können Sie aufgrund der Cache-Fähigkeit, dies mit regelmäßigen Abfragen zu beheben, selbst bei sehr vielen Clients sehr viel mit dem normalen Polling tun.