I have an API endpoint written for version and health of tomcat applications. It returns a json response with details. I wanted to know, how can i monitor any change in the json response in real time. I am building a dashboard on top of the endpoints.
I will be using django channels consumers to consume events in real time. But still stuck in how to detect real time changes in the response of API endpoints.
Changes in version endpoint are likely to happen after deployment.
EDIT 1
Let the version endpoint be /api/v1/version.
GET on this endpoint will return a json response
{
"version": "1.0.3-RELEASE",
"git_tag": "hot_fix"
}
After a deployment, the same json response will change.
Now a GET on the same endpoint will give you
{
"version":"1.0.4-RELEASE",
"git_tag": "JIRA2134"
}
I want to track this change real time. Rather than polling after every “x” minute and identifying a change.
Similar situation if for the health API endpoint.
Any help is welcome.Please let me know if this is not the right forum to ask the question.
4
You can’t push information from the end point itself. But since you control the deployment process you can add a push interface as part of the deployment.
For example.
Add a second interface which you can connect to with a push methodology such as long polling, queues or nservicebus. Have your clients connect to this in addition to the normal apis.
When your CI servers push a deployment to live have them also push a message to this second api, which in turn forwards it to all your clients
0
when you get response from end user handle it as simple as you handle response at client side [you can use HttpRequest.META] if your response is too bigger and require more time to process it you can create a other sample object and compare it with request.
if you haven’t need to process it at same time you can make its log and process it later we are using windows service to process it later[it will maintain your throughput]
5
If the endpoint cooperates: The endpoint could return a version, and a guaranteed validity time. So the message would be “1.0.3, valid until (some date at least a day away)”, until the switch to 1.0.4 gets close. If the server developer wants to release 1.0.4 on Wednesday 1pm the response changes to “1.0.3, valid until Wednesday 1pm”. If he misses the time by an hour, he changes to “valid until Wednesday 2pm”.
An alternative: Send a request with a large timeout value. The request sends which version it assumes, the response comes immediately if the version is different, or when the version changes, or just before the timeout.