This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
-
This Internet-Draft will expire on April 30, 2019.
+
This Internet-Draft will expire on August 30, 2019.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
thresholdValue: (optional) could be any valid JSON value, such as: string, number, object, array or literal. Determines the value above (or below) which the status changes from “pass” state to “warn” state or back. thresholdValue MUST only be present if observedValue is also present.
observedUnit (optional) SHOULD be present if observedValue is present. Calrifies the unit of measurement in which observedUnit is reported, e.g. for a time-based value it is important to know whether the time is reported in seconds, minutes, hours or something else. To make sure unit is denoted by a well-understood name or an abbreviation, it should be one of:
+
observedUnit (optional) SHOULD be present if observedValue is present. Clarifies the unit of measurement in which observedValue and thresholdValue are reported, e.g. for a time-based value it is important to know whether the time is reported in seconds, minutes, hours or something else. To make sure unit is denoted by a well-understood name or an abbreviation, it should be one of:
A common and standard term from a well-known source such as schema.org, IANA, microformats, or a standards document such as [RFC3339].
A URI that indicates extra semantics and processing rules that MAY be provided by a resource at the other end of the URI. URIs do not have to be dereferenceable, however. They are just a namespace, and the meaning of a namespace CAN be provided by any convenient means (e.g. publishing an RFC, Swagger document or a nicely printed book).
status (optional) has the exact same meaning as the top-level “output” element, but for the sub-component/downstream dependency represented by the details object.
time (optional) is the date-time, in ISO8601 format, at which the reading of the observedValue was recorded. This assumes that the value can be cached and the reading typically doesn’t happen in real time, for performance and scalability purposes.
+
status (optional) has the exact same meaning as the top-level “output” element, but for the sub-component/downstream dependency represented by the details object.
output (optional) has the exact same meaning as the top-level “output” element, but for the sub-component/downstream dependency represented by the details object.
+
time (optional) is the date-time, in ISO8601 format, at which the reading of the observedValue was recorded. This assumes that the value can be cached and the reading typically doesn’t happen in real time, for performance and scalability purposes.
output (optional) has the exact same meaning as the top-level “output” element, but for the sub-component/downstream dependency represented by the details object.
links (optional) has the exact same meaning as the top-level “output” element, but for the sub-component/downstream dependency represented by the details object.
+
links (optional) has the exact same meaning as the top-level “output” element, but for the sub-component/downstream dependency represented by the details object.
diff --git a/draft-inadarei-api-health-check-03.txt b/draft-inadarei-api-health-check-03.txt
index 98d8a20..6ecb291 100644
--- a/draft-inadarei-api-health-check-03.txt
+++ b/draft-inadarei-api-health-check-03.txt
@@ -3,9 +3,9 @@
Network Working Group I. Nadareishvili
-Internet-Draft October 27, 2018
+Internet-Draft February 26, 2018
Intended status: Informational
-Expires: April 30, 2019
+Expires: August 30, 2019
Health Check Response Format for HTTP APIs
@@ -48,14 +48,14 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on April 30, 2019.
+ This Internet-Draft will expire on August 30, 2019.
-Nadareishvili Expires April 30, 2019 [Page 1]
+Nadareishvili Expires August 30, 2019 [Page 1]
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
Copyright Notice
@@ -91,29 +91,30 @@ Table of Contents
4.1. componentId . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. componentType . . . . . . . . . . . . . . . . . . . . . . 7
4.3. observedValue . . . . . . . . . . . . . . . . . . . . . . 7
- 4.4. observedUnit . . . . . . . . . . . . . . . . . . . . . . 7
- 4.5. status . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 4.6. time . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 4.7. output . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 4.8. links . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4.4. thresholdValue . . . . . . . . . . . . . . . . . . . . . 7
+ 4.5. observedUnit . . . . . . . . . . . . . . . . . . . . . . 7
+ 4.6. status . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4.7. time . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4.8. output . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4.9. links . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Example Output . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. Creating and Serving Health Responses . . . . . . . . . . . . 12
- 10. Consuming Health Check Responses . . . . . . . . . . . . . . 12
+ 10. Consuming Health Check Responses . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13
- 11.2. Informative References . . . . . . . . . . . . . . . . . 13
- 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 11.2. Informative References . . . . . . . . . . . . . . . . . 14
-Nadareishvili Expires April 30, 2019 [Page 2]
+Nadareishvili Expires August 30, 2019 [Page 2]
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
+ 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
@@ -164,10 +165,9 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
-
-Nadareishvili Expires April 30, 2019 [Page 3]
+Nadareishvili Expires August 30, 2019 [Page 3]
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
3. API Health Response
@@ -221,9 +221,9 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
-Nadareishvili Expires April 30, 2019 [Page 4]
+Nadareishvili Expires August 30, 2019 [Page 4]
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
preserve stable interface. However implementation of an API may
@@ -277,9 +277,9 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
-Nadareishvili Expires April 30, 2019 [Page 5]
+Nadareishvili Expires August 30, 2019 [Page 5]
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
single-node sub-component (or if presence of nodes is not relevant),
@@ -333,9 +333,9 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
-Nadareishvili Expires April 30, 2019 [Page 6]
+Nadareishvili Expires August 30, 2019 [Page 6]
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
4.2. componentType
@@ -366,19 +366,34 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
observedValue: (optional) could be any valid JSON value, such as:
string, number, object, array or literal.
-4.4. observedUnit
+4.4. thresholdValue
+
+ thresholdValue: (optional) could be any valid JSON value, such as:
+ string, number, object, array or literal. Determines the value above
+ (or below) which the status changes from "pass" state to "warn" state
+ or back. thresholdValue MUST only be present if observedValue is also
+ present.
+
+4.5. observedUnit
observedUnit (optional) SHOULD be present if observedValue is
- present. Calrifies the unit of measurement in which observedUnit is
- reported, e.g. for a time-based value it is important to know whether
- the time is reported in seconds, minutes, hours or something else.
- To make sure unit is denoted by a well-understood name or an
- abbreviation, it should be one of:
+ present. Clarifies the unit of measurement in which observedValue
+ and thresholdValue are reported, e.g. for a time-based value it is
+ important to know whether the time is reported in seconds, minutes,
+ hours or something else. To make sure unit is denoted by a well-
+ understood name or an abbreviation, it should be one of:
o A common and standard term from a well-known source such as
schema.org, IANA, microformats, or a standards document such as
[RFC3339].
+
+
+Nadareishvili Expires August 30, 2019 [Page 7]
+
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
+
+
o A URI that indicates extra semantics and processing rules that MAY
be provided by a resource at the other end of the URI. URIs do
not have to be dereferenceable, however. They are just a
@@ -386,34 +401,26 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
convenient means (e.g. publishing an RFC, Swagger document or a
nicely printed book).
-
-
-
-Nadareishvili Expires April 30, 2019 [Page 7]
-
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
-
-
-4.5. status
+4.6. status
status (optional) has the exact same meaning as the top-level
"output" element, but for the sub-component/downstream dependency
represented by the details object.
-4.6. time
+4.7. time
time (optional) is the date-time, in ISO8601 format, at which the
reading of the observedValue was recorded. This assumes that the
value can be cached and the reading typically doesn't happen in real
time, for performance and scalability purposes.
-4.7. output
+4.8. output
output (optional) has the exact same meaning as the top-level
"output" element, but for the sub-component/downstream dependency
represented by the details object.
-4.8. links
+4.9. links
links (optional) has the exact same meaning as the top-level "output"
element, but for the sub-component/downstream dependency represented
@@ -435,6 +442,14 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
"version": "1",
"releaseID": "1.2.2",
"notes": [""],
+
+
+
+Nadareishvili Expires August 30, 2019 [Page 8]
+
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
+
+
"output": "",
"serviceID": "f03e522f-1f44-4062-9b55-9587f91c9c41",
"description": "health of authz service",
@@ -442,14 +457,6 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
"cassandra:responseTime": [
{
"componentId": "dfd6cf2b-1b6e-4412-a0b8-f6f7797a60d2",
-
-
-
-Nadareishvili Expires April 30, 2019 [Page 8]
-
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
-
-
"componentType": "datastore",
"observedValue": 250,
"observedUnit": "ms",
@@ -491,6 +498,14 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
"time": "2018-01-17T03:36:48Z",
"output": ""
},
+
+
+
+Nadareishvili Expires August 30, 2019 [Page 9]
+
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
+
+
{
"componentId": "6fd416e0-8920-410f-9c7b-c479000f7227",
"node": 2,
@@ -498,14 +513,6 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
"observedValue": 85,
"observedUnit": "percent",
"status": "warn",
-
-
-
-Nadareishvili Expires April 30, 2019 [Page 9]
-
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
-
-
"time": "2018-01-17T03:36:48Z",
"output": ""
}
@@ -547,20 +554,21 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
attacks. In some cases the health check endpoints may need to be
authenticated and institute role-based access control.
-7. IANA Considerations
- The media type for health check response is application/health+json.
- o Media type name: application
- o Media subtype name: health+json
+Nadareishvili Expires August 30, 2019 [Page 10]
+
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
+7. IANA Considerations
-Nadareishvili Expires April 30, 2019 [Page 10]
-
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
+ The media type for health check response is application/health+json.
+
+ o Media type name: application
+ o Media subtype name: health+json
o Required parameters: n/a
@@ -602,21 +610,21 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
3. File extension(s): .json
- 4. Macintosh file type code: TEXT
- 5. Object Identifiers: n/a
- o General Comments:
- o Person to contact for further information:
+Nadareishvili Expires August 30, 2019 [Page 11]
+
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
+ 4. Macintosh file type code: TEXT
+ 5. Object Identifiers: n/a
-Nadareishvili Expires April 30, 2019 [Page 11]
-
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
+ o General Comments:
+ o Person to contact for further information:
1. Name: Irakli Nadareishvili
@@ -656,23 +664,24 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
o Custom link relation types, as well as the URIs for variables,
should lead to documentation for those constructs.
-10. Consuming Health Check Responses
- Clients might use health check responses in a variety of ways.
- Note that the health check response is a "living" document; links
- from the health check response MUST NOT be assumed to be valid beyond
- the freshness lifetime of the health check response, as per HTTP's
- caching model [RFC7234].
+Nadareishvili Expires August 30, 2019 [Page 12]
+
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
-Nadareishvili Expires April 30, 2019 [Page 12]
-
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
+10. Consuming Health Check Responses
+ Clients might use health check responses in a variety of ways.
+
+ Note that the health check response is a "living" document; links
+ from the health check response MUST NOT be assumed to be valid beyond
+ the freshness lifetime of the health check response, as per HTTP's
+ caching model [RFC7234].
As a result, clients ought to cache the health check response (as per
[RFC7234]), to avoid fetching it before every interaction (which
@@ -710,6 +719,17 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
DOI 10.17487/RFC8288, October 2017,
.
+
+
+
+
+
+
+Nadareishvili Expires August 30, 2019 [Page 13]
+
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
+
+
11.2. Informative References
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
@@ -721,15 +741,6 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
RFC 6838, DOI 10.17487/RFC6838, January 2013,
.
-
-
-
-
-Nadareishvili Expires April 30, 2019 [Page 13]
-
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
-
-
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
@@ -770,15 +781,4 @@ Author's Address
-
-
-
-
-
-
-
-
-
-
-
-Nadareishvili Expires April 30, 2019 [Page 14]
+Nadareishvili Expires August 30, 2019 [Page 14]
diff --git a/draft-inadarei-api-health-check-03.xml b/draft-inadarei-api-health-check-03.xml
index a2b985a..3627bf1 100644
--- a/draft-inadarei-api-health-check-03.xml
+++ b/draft-inadarei-api-health-check-03.xml
@@ -1,6 +1,6 @@
-
+
@@ -282,14 +282,21 @@ Swagger document or a nicely printed book).
observedValue: (optional) could be any valid JSON value, such as: string, number,
object, array or literal.
+
+
+thresholdValue: (optional) could be any valid JSON value, such as: string, number,
+object, array or literal. Determines the value above (or below) which the status
+changes from “pass” state to “warn” state or back. thresholdValue MUST only be
+present if observedValue is also present.
+
-observedUnit (optional) SHOULD be present if observedValue is present. Calrifies
-the unit of measurement in which observedUnit is reported, e.g. for a time-based
-value it is important to know whether the time is reported in seconds, minutes,
-hours or something else. To make sure unit is denoted by a well-understood name
-or an abbreviation, it should be one of:
+observedUnit (optional) SHOULD be present if observedValue is present. Clarifies
+the unit of measurement in which observedValue and thresholdValue are reported,
+e.g. for a time-based value it is important to know whether the time is reported
+in seconds, minutes, hours or something else. To make sure unit is denoted by a
+well-understood name or an abbreviation, it should be one of:A common and standard term from a well-known source such as schema.org, IANA,
@@ -501,7 +508,7 @@ authoring RFCs easily.
-When making a health check endpoint available, there are a few things to keep
+When making an health check endpoint available, there are a few things to keep
in mind:
@@ -695,144 +702,145 @@ a fresh copy of the health check response, to assure that it is up-to-date.
diff --git a/draft.md b/draft.md
index db12d10..05149ac 100644
--- a/draft.md
+++ b/draft.md
@@ -240,13 +240,19 @@ a type of the component and could be one of:
observedValue: (optional) could be any valid JSON value, such as: string, number,
object, array or literal.
+## thresholdValue
+thresholdValue: (optional) could be any valid JSON value, such as: string, number,
+object, array or literal. Determines the value above (or below) which the status
+changes from "pass" state to "warn" state or back. thresholdValue MUST only be
+present if observedValue is also present.
+
## observedUnit
-observedUnit (optional) SHOULD be present if observedValue is present. Calrifies
-the unit of measurement in which observedUnit is reported, e.g. for a time-based
-value it is important to know whether the time is reported in seconds, minutes,
-hours or something else. To make sure unit is denoted by a well-understood name
-or an abbreviation, it should be one of:
+observedUnit (optional) SHOULD be present if observedValue is present. Clarifies
+the unit of measurement in which observedValue and thresholdValue are reported,
+e.g. for a time-based value it is important to know whether the time is reported
+in seconds, minutes, hours or something else. To make sure unit is denoted by a
+well-understood name or an abbreviation, it should be one of:
* A common and standard term from a well-known source such as schema.org, IANA,
microformats, or a standards document such as {{RFC3339}}.
diff --git a/index.html b/index.html
index e15dee5..a445c06 100644
--- a/index.html
+++ b/index.html
@@ -390,11 +390,12 @@
-
-
-
-
-
+
+
+
+
+
+
@@ -407,12 +408,12 @@
-
+
-
+
@@ -429,14 +430,14 @@
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
-
This Internet-Draft will expire on April 30, 2019.
+
This Internet-Draft will expire on August 30, 2019.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
thresholdValue: (optional) could be any valid JSON value, such as: string, number, object, array or literal. Determines the value above (or below) which the status changes from “pass” state to “warn” state or back. thresholdValue MUST only be present if observedValue is also present.
observedUnit (optional) SHOULD be present if observedValue is present. Calrifies the unit of measurement in which observedUnit is reported, e.g. for a time-based value it is important to know whether the time is reported in seconds, minutes, hours or something else. To make sure unit is denoted by a well-understood name or an abbreviation, it should be one of:
+
observedUnit (optional) SHOULD be present if observedValue is present. Clarifies the unit of measurement in which observedValue and thresholdValue are reported, e.g. for a time-based value it is important to know whether the time is reported in seconds, minutes, hours or something else. To make sure unit is denoted by a well-understood name or an abbreviation, it should be one of:
A common and standard term from a well-known source such as schema.org, IANA, microformats, or a standards document such as [RFC3339].
A URI that indicates extra semantics and processing rules that MAY be provided by a resource at the other end of the URI. URIs do not have to be dereferenceable, however. They are just a namespace, and the meaning of a namespace CAN be provided by any convenient means (e.g. publishing an RFC, Swagger document or a nicely printed book).
status (optional) has the exact same meaning as the top-level “output” element, but for the sub-component/downstream dependency represented by the details object.
time (optional) is the date-time, in ISO8601 format, at which the reading of the observedValue was recorded. This assumes that the value can be cached and the reading typically doesn’t happen in real time, for performance and scalability purposes.
+
status (optional) has the exact same meaning as the top-level “output” element, but for the sub-component/downstream dependency represented by the details object.
output (optional) has the exact same meaning as the top-level “output” element, but for the sub-component/downstream dependency represented by the details object.
+
time (optional) is the date-time, in ISO8601 format, at which the reading of the observedValue was recorded. This assumes that the value can be cached and the reading typically doesn’t happen in real time, for performance and scalability purposes.
output (optional) has the exact same meaning as the top-level “output” element, but for the sub-component/downstream dependency represented by the details object.
links (optional) has the exact same meaning as the top-level “output” element, but for the sub-component/downstream dependency represented by the details object.
+
links (optional) has the exact same meaning as the top-level “output” element, but for the sub-component/downstream dependency represented by the details object.
diff --git a/index.txt b/index.txt
index 98d8a20..6ecb291 100644
--- a/index.txt
+++ b/index.txt
@@ -3,9 +3,9 @@
Network Working Group I. Nadareishvili
-Internet-Draft October 27, 2018
+Internet-Draft February 26, 2018
Intended status: Informational
-Expires: April 30, 2019
+Expires: August 30, 2019
Health Check Response Format for HTTP APIs
@@ -48,14 +48,14 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on April 30, 2019.
+ This Internet-Draft will expire on August 30, 2019.
-Nadareishvili Expires April 30, 2019 [Page 1]
+Nadareishvili Expires August 30, 2019 [Page 1]
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
Copyright Notice
@@ -91,29 +91,30 @@ Table of Contents
4.1. componentId . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. componentType . . . . . . . . . . . . . . . . . . . . . . 7
4.3. observedValue . . . . . . . . . . . . . . . . . . . . . . 7
- 4.4. observedUnit . . . . . . . . . . . . . . . . . . . . . . 7
- 4.5. status . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 4.6. time . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 4.7. output . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 4.8. links . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4.4. thresholdValue . . . . . . . . . . . . . . . . . . . . . 7
+ 4.5. observedUnit . . . . . . . . . . . . . . . . . . . . . . 7
+ 4.6. status . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4.7. time . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4.8. output . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4.9. links . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Example Output . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. Creating and Serving Health Responses . . . . . . . . . . . . 12
- 10. Consuming Health Check Responses . . . . . . . . . . . . . . 12
+ 10. Consuming Health Check Responses . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13
- 11.2. Informative References . . . . . . . . . . . . . . . . . 13
- 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 11.2. Informative References . . . . . . . . . . . . . . . . . 14
-Nadareishvili Expires April 30, 2019 [Page 2]
+Nadareishvili Expires August 30, 2019 [Page 2]
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
+ 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
@@ -164,10 +165,9 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
-
-Nadareishvili Expires April 30, 2019 [Page 3]
+Nadareishvili Expires August 30, 2019 [Page 3]
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
3. API Health Response
@@ -221,9 +221,9 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
-Nadareishvili Expires April 30, 2019 [Page 4]
+Nadareishvili Expires August 30, 2019 [Page 4]
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
preserve stable interface. However implementation of an API may
@@ -277,9 +277,9 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
-Nadareishvili Expires April 30, 2019 [Page 5]
+Nadareishvili Expires August 30, 2019 [Page 5]
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
single-node sub-component (or if presence of nodes is not relevant),
@@ -333,9 +333,9 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
-Nadareishvili Expires April 30, 2019 [Page 6]
+Nadareishvili Expires August 30, 2019 [Page 6]
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
4.2. componentType
@@ -366,19 +366,34 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
observedValue: (optional) could be any valid JSON value, such as:
string, number, object, array or literal.
-4.4. observedUnit
+4.4. thresholdValue
+
+ thresholdValue: (optional) could be any valid JSON value, such as:
+ string, number, object, array or literal. Determines the value above
+ (or below) which the status changes from "pass" state to "warn" state
+ or back. thresholdValue MUST only be present if observedValue is also
+ present.
+
+4.5. observedUnit
observedUnit (optional) SHOULD be present if observedValue is
- present. Calrifies the unit of measurement in which observedUnit is
- reported, e.g. for a time-based value it is important to know whether
- the time is reported in seconds, minutes, hours or something else.
- To make sure unit is denoted by a well-understood name or an
- abbreviation, it should be one of:
+ present. Clarifies the unit of measurement in which observedValue
+ and thresholdValue are reported, e.g. for a time-based value it is
+ important to know whether the time is reported in seconds, minutes,
+ hours or something else. To make sure unit is denoted by a well-
+ understood name or an abbreviation, it should be one of:
o A common and standard term from a well-known source such as
schema.org, IANA, microformats, or a standards document such as
[RFC3339].
+
+
+Nadareishvili Expires August 30, 2019 [Page 7]
+
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
+
+
o A URI that indicates extra semantics and processing rules that MAY
be provided by a resource at the other end of the URI. URIs do
not have to be dereferenceable, however. They are just a
@@ -386,34 +401,26 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
convenient means (e.g. publishing an RFC, Swagger document or a
nicely printed book).
-
-
-
-Nadareishvili Expires April 30, 2019 [Page 7]
-
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
-
-
-4.5. status
+4.6. status
status (optional) has the exact same meaning as the top-level
"output" element, but for the sub-component/downstream dependency
represented by the details object.
-4.6. time
+4.7. time
time (optional) is the date-time, in ISO8601 format, at which the
reading of the observedValue was recorded. This assumes that the
value can be cached and the reading typically doesn't happen in real
time, for performance and scalability purposes.
-4.7. output
+4.8. output
output (optional) has the exact same meaning as the top-level
"output" element, but for the sub-component/downstream dependency
represented by the details object.
-4.8. links
+4.9. links
links (optional) has the exact same meaning as the top-level "output"
element, but for the sub-component/downstream dependency represented
@@ -435,6 +442,14 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
"version": "1",
"releaseID": "1.2.2",
"notes": [""],
+
+
+
+Nadareishvili Expires August 30, 2019 [Page 8]
+
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
+
+
"output": "",
"serviceID": "f03e522f-1f44-4062-9b55-9587f91c9c41",
"description": "health of authz service",
@@ -442,14 +457,6 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
"cassandra:responseTime": [
{
"componentId": "dfd6cf2b-1b6e-4412-a0b8-f6f7797a60d2",
-
-
-
-Nadareishvili Expires April 30, 2019 [Page 8]
-
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
-
-
"componentType": "datastore",
"observedValue": 250,
"observedUnit": "ms",
@@ -491,6 +498,14 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
"time": "2018-01-17T03:36:48Z",
"output": ""
},
+
+
+
+Nadareishvili Expires August 30, 2019 [Page 9]
+
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
+
+
{
"componentId": "6fd416e0-8920-410f-9c7b-c479000f7227",
"node": 2,
@@ -498,14 +513,6 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
"observedValue": 85,
"observedUnit": "percent",
"status": "warn",
-
-
-
-Nadareishvili Expires April 30, 2019 [Page 9]
-
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
-
-
"time": "2018-01-17T03:36:48Z",
"output": ""
}
@@ -547,20 +554,21 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
attacks. In some cases the health check endpoints may need to be
authenticated and institute role-based access control.
-7. IANA Considerations
- The media type for health check response is application/health+json.
- o Media type name: application
- o Media subtype name: health+json
+Nadareishvili Expires August 30, 2019 [Page 10]
+
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
+7. IANA Considerations
-Nadareishvili Expires April 30, 2019 [Page 10]
-
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
+ The media type for health check response is application/health+json.
+
+ o Media type name: application
+ o Media subtype name: health+json
o Required parameters: n/a
@@ -602,21 +610,21 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
3. File extension(s): .json
- 4. Macintosh file type code: TEXT
- 5. Object Identifiers: n/a
- o General Comments:
- o Person to contact for further information:
+Nadareishvili Expires August 30, 2019 [Page 11]
+
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
+ 4. Macintosh file type code: TEXT
+ 5. Object Identifiers: n/a
-Nadareishvili Expires April 30, 2019 [Page 11]
-
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
+ o General Comments:
+ o Person to contact for further information:
1. Name: Irakli Nadareishvili
@@ -656,23 +664,24 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
o Custom link relation types, as well as the URIs for variables,
should lead to documentation for those constructs.
-10. Consuming Health Check Responses
- Clients might use health check responses in a variety of ways.
- Note that the health check response is a "living" document; links
- from the health check response MUST NOT be assumed to be valid beyond
- the freshness lifetime of the health check response, as per HTTP's
- caching model [RFC7234].
+Nadareishvili Expires August 30, 2019 [Page 12]
+
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
-Nadareishvili Expires April 30, 2019 [Page 12]
-
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
+10. Consuming Health Check Responses
+ Clients might use health check responses in a variety of ways.
+
+ Note that the health check response is a "living" document; links
+ from the health check response MUST NOT be assumed to be valid beyond
+ the freshness lifetime of the health check response, as per HTTP's
+ caching model [RFC7234].
As a result, clients ought to cache the health check response (as per
[RFC7234]), to avoid fetching it before every interaction (which
@@ -710,6 +719,17 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
DOI 10.17487/RFC8288, October 2017,
.
+
+
+
+
+
+
+Nadareishvili Expires August 30, 2019 [Page 13]
+
+Internet-Draft Health Check Response Format for HTTP APIs February 2018
+
+
11.2. Informative References
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
@@ -721,15 +741,6 @@ Internet-Draft Health Check Response Format for HTTP APIs October 2018
RFC 6838, DOI 10.17487/RFC6838, January 2013,
.
-
-
-
-
-Nadareishvili Expires April 30, 2019 [Page 13]
-
-Internet-Draft Health Check Response Format for HTTP APIs October 2018
-
-
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
@@ -770,15 +781,4 @@ Author's Address
-
-
-
-
-
-
-
-
-
-
-
-Nadareishvili Expires April 30, 2019 [Page 14]
+Nadareishvili Expires August 30, 2019 [Page 14]