anchor.diff:  * 200 for successful retrieval of an object
   * 204 when retrieving a subtree that would exist, but has no content. E.g. when the application-specific subtree has no application specific metrics defined.
   * 404 if a directly-addressed item does not exist. This may be a non-existing sub-tree or non-existing object
  -* 406 if the HTTP Accept Header in the request header cannot be handled by the server.
  +* 406 if the HTTP Accept Header in the request cannot be handled by the server.
   * 500 to indicate that a request failed due to "bad health". The body SHOULD contain details if possible { "details": <text> }
   
   The API MUST NOT return a 500 Internal Server Error code to represent a non-existing resource.
  
positive.code: 
  ===== Vendor specific Metrics
  
  It is possible for Microprofile server implementors to supply their specific metrics data on top
  of the basic set of required metrics.
  Vendor specific metrics are exposed under `/metrics/vendor`.
  
  Examples for vendor specific data could be metrics like:
  
  * OSGi statistics if the Microprofile-enabled container internally runs on top of OSGi.
  * Statistics of some internal caching modules
  
  Vendor specific metrics are not supposed to be portable between different implementations
  of Microprofile servers, even if they are compliant with the same version of this specification.
  
  [[supplying_of_tags]]
  ==== Supplying of Tags
  
negative.code: standard to expose metrics, but remote-JMX is not easy to deal with and
  especially does not fit well in a polyglot environment where other services
  are not running on the JVM.
  To enable monitoring in an easy fashion it is necessary that all MicroProfile
  implementations follow a certain standard with respect to (base) API path,
  data types involved, always available metrics and return codes used.
  
  