Pubblica / sottoscrivi tramite callback HTTP?

Question

Pubblica / sottoscrivi tramite callback HTTP?

#1 da (1 voti)
#2 da (1 voti)

1

Il mio team ha il compito di creare un sistema di pubblicazione / sottoscrizione per i messaggi REST in entrata. Il 99% delle volte, questo sistema verrà utilizzato per le notifiche tra diversi processi sulla stessa CPU, ma dovremo anche supportare la notifica sulla rete.

Stiamo considerando un modello basato sul REST, in cui un cliente si iscrive con un POST come:

curl https://brokeripaddress/REST/function/path/subscribe -H 'Content-Type: application/json' -d '{"subscription-ip-address":"192.168.1.1", "subscription-method-filter":"*"}' -X POST

Quindi, quando il nostro servizio REST riceve una chiamata a /REST/function/path , duplicheremo quella richiesta, inviandola all'indirizzo IP di sottoscrizione specificato.

Qualcuno ha esperienza con modelli simili? Si tratta di un modo ragionevole per implementare la pubblicazione / sottoscrizione o ci sono evidenti insidie che ci mancano?

design rest http callbacks pubsub

posta therealmitchconnors 26.02.2016 - 17:17

fonte

2 risposte

Leggi altre domande sui tag design rest http callbacks pubsub

Utilizzo di più ambienti e vNext best practice I nomi delle variabili possono corrispondere ai nomi dei campi? [chiuso]

score 1 · Answer 1

1

Dai un'occhiata a WebHooks per un esempio di approccio:

A web application implementing WebHooks will POST a message to a URL when certain things happen.

risposta data 09.08.2016 - 11:47

fonte

score 1 · Answer 2

Prima di tutto, potresti trovare soluzioni pub / sub preconfezionate come AMQP o STOMP più adatte alle tue esigenze piuttosto che svilupparle.

Tuttavia, se è necessario fare affidamento sul trasporto HTTP tra client e broker e non si desidera / non è necessario introdurre una soluzione complessa, preferirei effettuare la sottoscrizione tramite richieste GET di vecchia data a endpoint REST definiti. Quindi estrarre i messaggi anziché essere trasferiti dal broker.

Il client invia la richiesta GET con gli attributi di sottoscrizione incorporati come interrogare i parametri all'endpoint, attende la risposta.
Quando un messaggio corrisponde, viene immediatamente inviato al client come al solito risposta HTTP.
Quando la coda è vuota, la richiesta rimane in attesa fino a quando non viene raggiunto alcun abbinamento o si verifica un timeout.

È possibile migliorare il protocollo con le risposte in batch, quindi più messaggi vengono restituiti in un batch se corrispondenti.

È necessario implementare un tipo di numero di sequenza di messaggi univoco rispetto all'endpoint, in modo che il client possa richiedere qualsiasi messaggio più recente dell'ultimo ricevuto. Ed è il cliente che è responsabile di conservare la cronologia e lo stato dell'abbonamento.

Se implementi la persistenza puoi riprodurre qualsiasi sequenza di messaggi di iscrizione, ad esempio se devi eseguire un debug forense.

La parte di pubblicazione viene ancora eseguita tramite la richiesta POST allo stesso endpoint REST. Oppure puoi incorporare l'endpoint nell'applicazione di pubblicazione e saltare completamente l'overhead del broker.

Se implementato correttamente, non dovresti perdere alcun messaggio in caso di utente disconnesso / fallito, cosa che potrebbe accadere se spandi i messaggi dal broker agli abbonati.