Giters

inadarei / rfc-healthcheck

Health Check Response RFC Draft for HTTP APIs

Home Page:https://inadarei.github.io/rfc-healthcheck/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Align with Microprofile Health Check spec

inadarei opened this issue · comments

commented

Find ways in which this RFC can better align with the microprofile spec for health checks: https://microprofile.io/project/eclipse/microprofile-health

commented

One immediate opportunity: aligning with "checks" field instead of RFC's current "details", since there were concerns about "details" in RFC already: #20

commented

MP Health recently broke back-compat by renaming "outcome"/"state" to "status"/"status". The only acceptable rationale (IMO) was to align with Spring Health Checks. Where MP Health is "checks"/"data", Spring is "details"/"details". So if we're really looking to synergize with Spring, then we are only part way there.

The outcome/state to status/status change kind of irked me. I did a big audit of popular health check outputs last night, and there is little to no overall consistency or emergent standards here.

To make better use of MP Health's 2.0 breaking changes, I'm trying to expand the scope of the considerations we will make so that we aren't breaking things just for nitpicky name changes like "I prefer status", "but I prefer outcome", "I don't care I just don't want you breaking my control plane automations", etc.

commented

Initial PR: #28

There're currently two major differences between RFC and microprofiles standard:

  1. In Microprofiles, checks is a JSON array, and a name of a check is a property. This is significantly harder to parse for clients than having the name as a key of a JSON object. Specifically: if a client wants to access a specific check, it would need to enumerate the checks array and compare 'name' property to the one it is interested in. In contrast, with JSON object a client gets direct access to any named check. The only reason why you would use an array, with a name, instead of a JSON object is if you expect duplicates. I don't think that is the case for checks, so parsing complication is unnecessary?

  2. In microprofiles, all of the details about the status are stashed-away into an undefined "bag of properties" called "data". While that may seem very flexible and extensible - it is also an anti-pattern. If we don't define the semantic meaning of expected properties - what is the point of having the standard in the first place? You cannot build interoperable middleware or clients with just "data", so it somewhat beats [some of] the purpose of having a standard in the first place.

commented

P.S. I noticed that @derekm already had 1st difference submitted as a change request in eclipse/microprofile-health#110