I have an ASP.NET Web API 2 web service. This is the interface customers will use to submit data.
I have a Windows Service running on an internal server. I will be sending the customer's POST data to this service adding a unique ID to the message.
There exists another service running on another internal server that will be communicated via pure asynchronous socket programming using TCPClient. By this I mean when sending a request I will not get a response back right away. I will have a TCPClient listener that will recieve responses after some time (within a few seconds) and I want to publish the response via ZeroMQ back too the Web API.
For each Web API Request, I was thinking of using ZeroMQ's Fire and Forget pattern to send the data with the Unique ID (serialized as a JSON string) to the Windows Service. I will then create a ZeroMQ Subcriber looking for the Unique ID.
The Windows Service on startup will bind a ZeroMQ socket for the fire and forget messages and will bind a socket for the sub/pub messages.
Is this an optimized solution? Is there a better way to handle the communication between the web api and web service?
Thanks.
Best Answer
WEB Api requests are Stateless & Synchronous. that means they don't maintain an open connection/state and will timeout after a while.
When your API sends a message to the windows service and then subscribe to events coming back, it will be subject to the how long the HTTP connection will be held open by the API client.
I can think of some better solutions here:
1- Pulling (works well for any client): Allow the clients to pull for updates by returning back a unique request ID immediately to the API client and another API endpoint to ask for progress of those requests.
2- Webhooks (works well with web-based clients/websites): a client can setup a URL to receive the status updates for their requests, then your windows service can call those URLs with status updates once the Socket returns the data.