RabbitMQ Anfrage/Antwort Payload Struktur

Question

Ich entwerfe ein System, das RabbitMQ für die Anfrage/Antwort zwischen den Anwendungen verwendet.

Ich bin es gewohnt, mit REST-APIs zu arbeiten, und von diesem Hintergrund ausgehend habe ich darüber nachgedacht, wie ich Nachrichten strukturieren kann, wenn ich Anfrage/Antwort mache.

Ich brauche es zu strukturieren mehrere Szenarien behandeln:

• Erste/Daten von einem entfernten Server
• Erstellen von Daten auf einem entfernten Server
• Umgang mit Client-Seite Fehler

abfragt Ich plane, die Nutzlast JSON formatiert zu haben. Und ich habe darüber nachgedacht, eine Art von HTTP-ähnlichen Antwortcodes zu verwenden (vielleicht mit den gleichen Codes?) Und den Antwortcode als Eigenschaft/Kopfzeile der Nachricht festzulegen.

Zum Abrufen/Abfragen meiner Idee war eine Abfrageeigenschaft im Nutzlastobjekt.

Aber das brachte mich dazu zu denken, dass ich dies zu sehr wie REST-APIs denken könnte und es könnte eine bessere, etabliertere Methode geben, dies zu tun.

Ich habe das Buch "RabbitMQ in Action" gelesen, während ich dies aufstelle, aber ich sehe dort keine Erwähnung. Mein Google-Fu hat mich auch gescheitert und keine Ergebnisse geliefert.

Jeder mit Erfahrung bereit zu teilen, wie sie ihre Nachrichten strukturieren?

Answer 1

Wenn Sie RabbitMQ in einem Anfrage/Antwort-Szenario zwischen Anwendungen verwenden, die bereits für REST-Aufrufe bekannt oder implementiert sind, müssen Sie in RabbitMQ nicht vom Nachrichtenformat abweichen.

Von Ihrer Frage, was ich erfahre ist, dass RabbitMQ als Zwischenserver zwischen Ihrer Anwendung fungiert. Sie erwähnen drei Szenarien. Wenn Sie Daten abrufen und Daten schreiben, fungiert RabbitMQ hier nur als Router zwischen der Anwendung, die Daten abrufen oder schreiben soll, und der Anwendung, die Daten abruft und schreibt. Wenn es so ist, gibt es bereits ein Standard-Nachrichtenformat, das die Serving-Anwendung (der Server mit Daten) unterstützen kann. Angenommen, es ist noch kein Standard definiert. In diesem Fall können Sie im Hinblick darauf denken, was die Anwendung in der Anforderungsnutzlast erwartet. Vergessen Sie den Intermediate RabbitMQ-Server während dieser Phase. Das Nachdenken über die RabbitMQ-Nachrichten kann Sie davon abhalten, die Best Practices zu verwenden.

Wie bei den clientseitigen Fehlern können Sie die HTTP-Statuscodes nicht direkt als Header festlegen, da dies die RabbitMQ-Fehler im Consumer beeinträchtigen würde. Ich glaube, in diesem Fall müssen Sie eine Anpassung verwenden, indem Sie einen benutzerdefinierten Header übergeben und ihn später in einen HTTP-Statuscode umwandeln.