I'm working on a system that integrates with several third party services via APIs. Those services require authentication.
Usually, the services are implemented as REST APIs using HTTP. My system assumes that the requests made to the third party services are stateless. However, some of them are starting to provide WebSocket APIs as well, and in some cases, they are replacing the REST APIs with WebSocket ones. I'm not sure that my system's assumption about the requests being stateless is valid anymore.
With the REST APIs, my architecture considers that my calls to the third party services are stateless, since the authentication is handled by a token sent with every request. The architecture looks like this:
my system -> my stateless service wrapper -> HTTP REST -> third party service
When dealing with WebSockets, the authentication step will be done every time that I connect to the service, which feels wrong to me.
I'm considering using the following architecture instead, which tries to :
my system -> HTTP REST -> my stateful service wrapper -> WebSocket -> third party service
With this new architecture, I will keep a session open as much as I can, and my system will still work under the assumption that its requests are stateless. However, now I have to deal with a new internal service, which is my stateful wrapper sitting between my system and the WebSocket endpoint.
Since I'm new to WebSockets, I might be missing something here. Is my approach good enough? If not, what would you change in it?