Utilizzo di richieste REST di breve durata per ottenere messaggi da una coda di messaggi per i client

Question

Utilizzo di richieste REST di breve durata per ottenere messaggi da una coda di messaggi per i client

#1 da (1 voti)

2

Vorrei mettere insieme un sistema in cui i client ottengano messaggi da un'API REST, ma con il produttore che è in grado di utilizzare la semantica di una coda di messaggi: ad es. ordinamento di messaggi, una casella di posta di destinazione, ecc.

Immagino di poter avere una coda di messaggi per client.

Quando un client si connette a uno degli endpoint WebStore / REST senza stato N per OTTENERE nuovi messaggi, tutti i nuovi messaggi vengono rimossi dalla coda del client nella coda messaggi, impacchettati e inviati al client come risposta a GET.

Penso che ci siano alcuni problemi con questo approccio, però.

Sembra che ogni richiesta REST crei una nuova connessione alla coda dei messaggi (o forse ci sia un certo numero di connessioni - ma le cassette postali dovrebbero essere abilmente commutabili nella connessione)

Inoltre, non sono sicuro di come gestire il caso quando un client riceve un elenco di messaggi come risposta a un GET, muore a metà del processo e deve ri-richiedere i messaggi che è già stato dato. La coda dovrebbe avere un certo livello di persistenza e alcune capacità di riavvolgimento.

Le mie domande sono: sto andando giù per la strada giusta qui? Cosa posso fare su questi problemi e mi mancano altre insidie? O forse c'è un modo completamente diverso per farlo che potrebbe essere più ottimale?

architecture rest message-queue

posta adapt-dev 02.11.2015 - 03:39

fonte

1 risposta

Leggi altre domande sui tag architecture rest message-queue

Quale sarà la migliore pratica per gestire la voce duplicata in DB in Spring MVC, lanciando Exception o in altro modo? Dovrebbero essere incluse demo e app di esempio nello stesso repository git del codice sorgente del progetto?

score 1 · Answer 1

Non è perché usi la semantica di una coda che hai bisogno di una coda effettiva per sostenere il tuo servizio REST. È molto possibile creare un servizio che utilizza semantica simile alla coda, ma che è supportato da un database.

In tal caso, non avresti una nuova connessione per richiesta di REST ma trarrai vantaggio dal pool di connessioni. L'uso di un database significa anche che i messaggi sono persistenti, quindi è possibile un certo riavvolgimento. Per quanto riguarda i ricevitori morenti, una richiesta di ottenere messaggi potrebbe inviare un elenco di messaggi al client in una richiesta e contrassegnarli come inviati nel database. L'applicazione ricevente potrebbe quindi confermare la ricezione di un messaggio da parte delle singole chiamate REST. Un lavoro in esecuzione a intermittenza potrebbe ri-contrassegnare i messaggi da inviare al client se non è stato ricevuto alcun riconoscimento dopo un certo periodo di tempo.