Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
I am interested in a guideline to understand how dependencies are considered when building the healthcheck functionality for an API. Like any functionality, the implementation of this feature sho...
Answer
#2: Post edited
by
meriton
·
2021-03-08T19:39:38Z (over 3 years ago)
- > I am interested in a guideline to understand how dependencies are considered when building the healthcheck functionality for an API.
- Like any functionality, the implementation of this feature should be guided by specific requirements. Who will be using that feature? What for?
For instance, if this healthcheck is an enpoint for a kubernetes liveness probe (which causes an automatic restart of the pod if it deems itself unhealthy), including external systems doesn't make sense, because restarting your app won't fix these systems.- On the other hand, if the health check is used by an actual human, they might be able to interpret a more nuanced response, and prefer being informed when optional dependencies fail.
- > I am interested in a guideline to understand how dependencies are considered when building the healthcheck functionality for an API.
- Like any functionality, the implementation of this feature should be guided by specific requirements. Who will be using that feature? What for?
- For instance, if this healthcheck is an endpoint for a kubernetes liveness probe (which causes an automatic restart of the pod if it deems itself unhealthy), including external systems doesn't make sense, because restarting your app won't fix these systems.
- On the other hand, if the health check is used by an actual human, they might be able to interpret a more nuanced response, and prefer being informed when optional dependencies fail.
#1: Initial revision
by
meriton
·
2021-03-08T19:39:17Z (over 3 years ago)
> I am interested in a guideline to understand how dependencies are considered when building the healthcheck functionality for an API. Like any functionality, the implementation of this feature should be guided by specific requirements. Who will be using that feature? What for? For instance, if this healthcheck is an enpoint for a kubernetes liveness probe (which causes an automatic restart of the pod if it deems itself unhealthy), including external systems doesn't make sense, because restarting your app won't fix these systems. On the other hand, if the health check is used by an actual human, they might be able to interpret a more nuanced response, and prefer being informed when optional dependencies fail.