Minor feedback

[taliaga]

Hi, nice initiative!

Fwiw, here some minor observations from my experience trying your proposal:

• There's a typo in section 4 (value eside).
• When talking about status:
  • 'warn' is mentioned with a MUST and later with a SHOULD.
  • It may be time-saving for the reader to give some specific examples of which HTTP codes could be used in the returns. It could say 207 for 'warn' and 424 for 'fail' maybe? It's an example of course, but saves time having to go an read all http codes.
• In details, take "cassandra:connections" for example. It may be an overkill to use arrays. I believe if this proposal promotes "hierarchies" of health reports, then "cassandra:connections" should be responsible for aggregating the health of its upstream dependencies. Otherwise it may bring duplication and/or risk inconsistencies, wouldn't it?

Cheers!

[dret]

* There's a typo in section 4 (value eside).

#23

[inadarei]

Thank you Tomas.

• re "'warn' is mentioned with a MUST and later with a SHOULD." can you please give more info where this is happening or submit PR that fixes it? I am failing to find what you are referring to.

The reason details use arrays is to support multi-node downstream dependencies. And granted not all dependencies are multi-node, but if you allow arrays a value being sometimes an array and sometimes not would put undue hurdle on parsers (clients). Better to use single-value arrays.

[taliaga]

Added #25 regarding the MUST - SHOULD for warning status.

I totally agree that it;s better to play safe towards the single-element-array rather than falling short on accommodating use-cases. But just to understand, by "multi-node downstream" you mean like for example if service S depends on a 3 replica-set of mongoDB instances the array would be used to return the status of the three replicas?.