hello miqui.
meh. that's acceptable for a more homogeneous model where you're ok with
depending on whatever your environment provides. it's not so useful if
you look beyond one environment and think about API health in all of
your API landscape.
> ..so, then drop using URI /health and each API team have it with
> whatever they want to do?
if you think API health is important, then treating it as such (and not
saying "everybody roll their own!") might be a good idea. this has been
around for a little while:
https://tools.ietf.org/html/draft-inadarei-api-health-check
hopefully this will be brought into the new IETF HTTP API building
blocks group, as it would be a really useful standard to have. for now,
you can simply take it as inspiration, but it may still change.
cheers,
dret.
ps: also, thanks for the inspiration, i am giving a conference
presentation on standards tomorrow and will add this as a very nice
example!
https://apiconference.net/api-management/api-standards-balancing-chaos-and-rigidity/
--
erik wilde | mailto:
erik....@dret.net |
|
http://dret.net/netdret |
|
http://twitter.com/dret |