Con il sourcing di eventi, come ottenere la risposta di una chiamata che è un effetto collaterale?

Non sono sicuro di come potresti impedire che l'asincronia si propaghi fino al client.

Il controller potrebbe restituire immediatamente un 201 Created , insieme all'URI del ticket di supporto che ha inizialmente uno stato di Asked . Il client esegue il polling della risorsa (automaticamente o da iniziativa dell'utente) per controllarne lo stato finché non diventa Opened e ha un token.

È possibile assegnare il proprio token alla richiesta fornita dal controller e restituirlo. Quando il client chiede "Qual è lo stato della richiesta X?" ti consegnerà il tuo tuo token.

Questo approccio ha diverse proprietà utili. Innanzitutto, puoi restituire il token immediatamente che è ciò che desideri. In secondo luogo, non sei legato all'API esterna - quando, ad esempio, passerai a un altro sistema e vorresti migrare i problemi i tuoi token non dovranno essere modificati.

L'ovvio lato negativo è che dovrai mappare il token esterno a quello interno, ma non è un IMO di tipo show-stopper.

A patto che il tuo framework supporti richieste asincrone, se sai che opened-ticket sarà attivato a un certo punto puoi sottoscriverlo dall'interno dell'azione del controller (utilizzando qualsiasi infrastruttura disponibile per accedere a quell'evento). Una volta ricevuta una risposta, è sufficiente restituire le informazioni rilevanti al cliente.