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?

  • Do they provide any live data stream or...they're moving to WebSocket without any particular reason? The (maybe broken) stateless services assumption does change something in your client? – Adriano Repetti Jul 2 '18 at 6:46
  • in my case it is live data stream. I am trying to connect to multiple exchanges to stream websocket data for Forex – PirateApp Sep 3 '18 at 12:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.