Sto lavorando su un sistema che si integra con diversi servizi di terze parti tramite API. Questi servizi richiedono l'autenticazione.
Solitamente, i servizi sono implementati come API REST usando HTTP. Il mio sistema presuppone che le richieste fatte ai servizi di terze parti siano prive di status. Tuttavia, alcuni di loro stanno iniziando a fornire anche API WebSocket e, in alcuni casi, stanno sostituendo le API REST con quelle WebSocket. Non sono sicuro che l'ipotesi del mio sistema riguardo alle richieste di essere senza stato sia più valida.
Con le API REST, la mia architettura considera che le mie chiamate ai servizi di terze parti sono prive di stato, poiché l'autenticazione è gestita da un token inviato con ogni richiesta. L'architettura ha questo aspetto:
my system -> my stateless service wrapper -> HTTP REST -> third party service
Quando si ha a che fare con WebSockets, il passo di autenticazione sarà fatto ogni volta che mi collego al servizio, il che mi sembra sbagliato.
Sto considerando l'utilizzo della seguente architettura, che tenta di:
my system -> HTTP REST -> my stateful service wrapper -> WebSocket -> third party service
Con questa nuova architettura, terrò aperta una sessione il più possibile, e il mio sistema continuerà a funzionare nel presupposto che le sue richieste siano senza stato. Tuttavia, ora devo occuparmi di un nuovo servizio interno, che è il mio wrapper stateful che si trova tra il mio sistema e l'endpoint WebSocket.
Dato che sono nuovo di WebSockets, potrei mancare qualcosa qui. Il mio approccio è abbastanza buono? In caso contrario, cosa cambieresti in esso?