idnits 2.17.1 draft-inadarei-api-health-check-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o componentName: (optional) human-readable name for the component. MUST not contain a colon, in the name, since colon is used as a separator. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o measurementName: (optional) name of the measurement type (a data point type) that the status is reported for. MUST not contain a colon, in the name, since colon is used as a separator. The observation's name can be one of: -- The document date (December 31, 2019) is 1572 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 668 -- Looks like a reference, but probably isn't: '2' on line 670 -- Looks like a reference, but probably isn't: '3' on line 672 -- Looks like a reference, but probably isn't: '4' on line 674 == Unused Reference: 'RFC6838' is defined on line 651, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Nadareishvili 3 Internet-Draft December 31, 2019 4 Intended status: Informational 5 Expires: July 3, 2020 7 Health Check Response Format for HTTP APIs 8 draft-inadarei-api-health-check-04 10 Abstract 12 This document proposes a service health check response format for 13 HTTP APIs. 15 Note to Readers 17 *RFC EDITOR: please remove this section before publication* 19 The issues list for this draft can be found at 20 https://github.com/inadarei/rfc-healthcheck/issues [1]. 22 The most recent draft is at https://inadarei.github.io/rfc- 23 healthcheck/ [2]. 25 Recent changes are listed at https://github.com/inadarei/rfc- 26 healthcheck/commits/master [3]. 28 See also the draft's current status in the IETF datatracker, at 29 https://datatracker.ietf.org/doc/draft-inadarei-api-health-check/ 30 [4]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on July 3, 2020. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 68 3. API Health Response . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. status . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.2. version . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.3. releaseId . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3.4. notes . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.5. output . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.6. checks . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.7. links . . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3.8. serviceId . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3.9. description . . . . . . . . . . . . . . . . . . . . . . . 5 78 4. The Checks Object . . . . . . . . . . . . . . . . . . . . . . 5 79 4.1. componentId . . . . . . . . . . . . . . . . . . . . . . . 6 80 4.2. componentType . . . . . . . . . . . . . . . . . . . . . . 7 81 4.3. observedValue . . . . . . . . . . . . . . . . . . . . . . 7 82 4.4. observedUnit . . . . . . . . . . . . . . . . . . . . . . 7 83 4.5. status . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 4.6. affectedEndpoints . . . . . . . . . . . . . . . . . . . . 8 85 4.7. time . . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 4.8. output . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 4.9. links . . . . . . . . . . . . . . . . . . . . . . . . . . 8 88 4.10. Additional Keys . . . . . . . . . . . . . . . . . . . . . 8 89 5. Example Output . . . . . . . . . . . . . . . . . . . . . . . 9 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 92 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 93 9. Creating and Serving Health Responses . . . . . . . . . . . . 12 94 10. Consuming Health Check Responses . . . . . . . . . . . . . . 13 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 97 11.2. Informative References . . . . . . . . . . . . . . . . . 14 98 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 101 1. Introduction 103 The vast majority of modern APIs driving data to web and mobile 104 applications use HTTP [RFC7230] as their protocol. The health and 105 uptime of these APIs determine availability of the applications 106 themselves. In distributed systems built with a number of APIs, 107 understanding the health status of the APIs and making corresponding 108 decisions, for caching, failover or circuit-breaking, are essential 109 to the ability of providing highly-available solutions. 111 There exists a wide variety of operational software that relies on 112 the ability to read health check response of APIs. However, there is 113 currently no standard for the health check output response, so most 114 applications either rely on the basic level of information included 115 in HTTP status codes [RFC7231] or use task-specific formats. 117 Usage of task-specific or application-specific formats creates 118 significant challenges, disallowing any meaningful interoperability 119 across different implementations and between different tooling. 121 Standardizing a format for health checks can provide any of a number 122 of benefits, including: 124 o Flexible deployment - since operational tooling and API clients 125 can rely on rich, uniform format, they can be safely combined and 126 substituted as needed. 128 o Evolvability - new APIs, conforming to the standard, can safely be 129 introduced in any environment and ecosystem that also conforms to 130 the same standard, without costly coordination and testing 131 requirements. 133 This document defines a "health check" format using the JSON format 134 [RFC8259] for APIs to use as a standard point for the health 135 information they offer. Having a well-defined format for this 136 purpose promotes good practice and tooling. 138 2. Notational Conventions 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 3. API Health Response 146 Health Check Response Format for HTTP APIs uses the JSON format 147 described in [RFC8259] and has the media type "application/ 148 health+json". 150 Its content consists of a single mandatory root field ("status") and 151 several optional fields: 153 3.1. status 155 status: (required) indicates whether the service status is acceptable 156 or not. API publishers SHOULD use following values for the field: 158 o "pass": healthy (acceptable aliases: "ok" to support Node's 159 Terminus and "up" for Java's SpringBoot), 161 o "fail": unhealthy (acceptable aliases: "error" to support Node's 162 Terminus and "down" for Java's SpringBoot), and 164 o "warn": healthy, with some concerns. 166 The value of the status field is case-insensitive and is tightly 167 related with the HTTP response code returned by the health endpoint. 168 For "pass" status, HTTP response code in the 2xx-3xx range MUST be 169 used. For "fail" status, HTTP response code in the 4xx-5xx range 170 MUST be used. In case of the "warn" status, endpoints MUST return 171 HTTP status in the 2xx-3xx range, and additional information SHOULD 172 be provided, utilizing optional fields of the response. 174 A health endpoint is only meaningful in the context of the component 175 it indicates the health of. It has no other meaning or purpose. As 176 such, its health is a conduit to the health of the component. 177 Clients SHOULD assume that the HTTP response code returned by the 178 health endpoint is applicable to the entire component (e.g. a larger 179 API or a microservice). This is compatible with the behavior that 180 current infrastructural tooling expects: load-balancers, service 181 discoveries and others, utilizing health-checks. 183 3.2. version 185 version: (optional) public version of the service. 187 3.3. releaseId 189 releaseId: (optional) in well-designed APIs, backwards-compatible 190 changes in the service should not update a version number. APIs 191 usually change their version number as infrequently as possible, to 192 preserve stable interface. However, implementation of an API may 193 change much more frequently, which leads to the importance of having 194 separate "release number" or "releaseId" that is different from the 195 public version of the API. 197 3.4. notes 199 notes: (optional) array of notes relevant to current state of health 201 3.5. output 203 output: (optional) raw error output, in case of "fail" or "warn" 204 states. This field SHOULD be omitted for "pass" state. 206 3.6. checks 208 checks (optional) is an object that provides detailed health statuses 209 of additional downstream systems and endpoints which can affect the 210 overall health of the main API. Please refer to the "The Checks 211 Object" section for more information. 213 3.7. links 215 links (optional) is an object containing link relations and URIs 216 [RFC3986] for external links that MAY contain more information about 217 the health of the endpoint. All values of this object SHALL be URIs. 218 Keys MAY also be URIs. Per web-linking standards [RFC8288] a link 219 relationship SHOULD either be a common/registered one or be indicated 220 as a URI, to avoid name clashes. If a "self" link is provided, it 221 MAY be used by clients to check health via HTTP response code, as 222 mentioned above. 224 3.8. serviceId 226 serviceId (optional) is a unique identifier of the service, in the 227 application scope. 229 3.9. description 231 description (optional) is a human-friendly description of the 232 service. 234 4. The Checks Object 236 The "checks" object MAY have a number of unique keys, one for each 237 logical downstream dependency or sub-component. Since each sub- 238 component may be backed by several nodes with varying health 239 statuses, these keys point to arrays of objects. In case of a 240 single-node sub-component (or if presence of nodes is not relevant), 241 a single-element array SHOULD be used as the value, for consistency. 243 The key identifying an element in the object SHOULD be a unique 244 string within the details section. It MAY have two parts: 245 "{componentName}:{measurementName}", in which case the meaning of the 246 parts SHOULD be as follows: 248 o componentName: (optional) human-readable name for the component. 249 MUST not contain a colon, in the name, since colon is used as a 250 separator. 252 o measurementName: (optional) name of the measurement type (a data 253 point type) that the status is reported for. MUST not contain a 254 colon, in the name, since colon is used as a separator. The 255 observation's name can be one of: 257 * A pre-defined value from this spec. Pre-defined values 258 include: 260 + utilization 262 + responseTime 264 + connections 266 + uptime 268 * A common and standard term from a well-known source such as 269 schema.org, IANA or microformats. 271 * A URI that indicates extra semantics and processing rules that 272 MAY be provided by a resource at the other end of the URI. 273 URIs do not have to be dereferenceable, however. They are just 274 a namespace, and the meaning of a namespace CAN be provided by 275 any convenient means (e.g. publishing an RFC, Open API Spec 276 document or a nicely printed book). 278 On the value side of the equation, each "component details" object in 279 the array SHOULD have at least one key, and MAY have any or none of 280 the following object keys: 282 4.1. componentId 284 componentId: (optional) is a unique identifier of an instance of a 285 specific sub-component/dependency of a service. Multiple objects 286 with the same componentID MAY appear in the details, if they are from 287 different nodes. 289 4.2. componentType 291 componentType: (optional) SHOULD be present if componentName is 292 present. It's a type of the component and could be one of: 294 o Pre-defined value from this spec. Pre-defined values include: 296 * component 298 * datastore 300 * system 302 o A common and standard term from a well-known source such as 303 schema.org, IANA or microformats. 305 o A URI that indicates extra semantics and processing rules that MAY 306 be provided by a resource at the other end of the URI. URIs do 307 not have to be dereferenceable, however. They are just a 308 namespace, and the meaning of a namespace CAN be provided by any 309 convenient means (e.g. publishing an RFC, Swagger document or a 310 nicely printed book). 312 4.3. observedValue 314 observedValue: (optional) could be any valid JSON value, such as: 315 string, number, object, array or literal. 317 4.4. observedUnit 319 observedUnit (optional) SHOULD be present if observedValue is 320 present. Clarifies the unit of measurement in which observedUnit is 321 reported, e.g. for a time-based value it is important to know whether 322 the time is reported in seconds, minutes, hours or something else. 323 To make sure unit is denoted by a well-understood name or an 324 abbreviation, it SHOULD be one of: 326 o A common and standard term from a well-known source such as 327 schema.org, IANA, microformats, or a standards document such as 328 [RFC3339]. 330 o A URI that indicates extra semantics and processing rules that MAY 331 be provided by a resource at the other end of the URI. URIs do 332 not have to be dereferenceable, however. They are just a 333 namespace, and the meaning of a namespace CAN be provided by any 334 convenient means (e.g. publishing an RFC, Swagger document or a 335 nicely printed book). 337 4.5. status 339 status (optional) has the exact same meaning as the top-level 340 "output" element, but for the sub-component/downstream dependency 341 represented by the details object. 343 4.6. affectedEndpoints 345 affectedEndpoints (optional) is a JSON array containing URI Templates 346 as defined by [RFC6570]. This field SHOULD be omitted if the 347 "status" field is present and has value equal to "pass". A typical 348 API has many URI endpoints. Most of the time we are interested in 349 the overall health of the API, without diving into details. That 350 said, sometimes operational and resilience middleware needs to know 351 more details about the health of the API (which is why "checks" 352 property provides details). In such cases, we often need to indicate 353 which particular endpoints are affected by a particular check's 354 troubles vs. other endpoints that may be fine. 356 4.7. time 358 time (optional) is the date-time, in ISO8601 format, at which the 359 reading of the observedValue was recorded. This assumes that the 360 value can be cached and the reading typically doesn't happen in real 361 time, for performance and scalability purposes. 363 4.8. output 365 output (optional) has the exact same meaning as the top-level 366 "output" element, but for the sub-component/downstream dependency 367 represented by the details object. As is the case for the top-level 368 element, this field SHOULD be omitted for "pass" state of a 369 downstream dependency. 371 4.9. links 373 links (optional) has the exact same meaning as the top-level "output" 374 element, but for the sub-component/downstream dependency represented 375 by the details object. 377 4.10. Additional Keys 379 In addition to the above keys, additional user-defined keys MAY be 380 included in the 'component details' object. Implementations MAY 381 ignore any keys that are not part of the list of standard keys above. 383 5. Example Output 385 GET /health HTTP/1.1 386 Host: example.org 387 Accept: application/health+json 389 HTTP/1.1 200 OK 390 Content-Type: application/health+json 391 Cache-Control: max-age=3600 392 Connection: close 394 { 395 "status": "pass", 396 "version": "1", 397 "releaseId": "1.2.2", 398 "notes": [""], 399 "output": "", 400 "serviceId": "f03e522f-1f44-4062-9b55-9587f91c9c41", 401 "description": "health of authz service", 402 "checks": { 403 "cassandra:responseTime": [ 404 { 405 "componentId": "dfd6cf2b-1b6e-4412-a0b8-f6f7797a60d2", 406 "componentType": "datastore", 407 "observedValue": 250, 408 "observedUnit": "ms", 409 "status": "pass", 410 "affectedEndpoints" : [ 411 "/users/{userId}", 412 "/customers/{customerId}/status", 413 "/shopping/{anything}" 414 ], 415 "time": "2018-01-17T03:36:48Z", 416 "output": "" 417 } 418 ], 419 "cassandra:connections": [ 420 { 421 "componentId": "dfd6cf2b-1b6e-4412-a0b8-f6f7797a60d2", 422 "componentType": "datastore", 423 "observedValue": 75, 424 "status": "warn", 425 "time": "2018-01-17T03:36:48Z", 426 "output": "", 427 "links": { 428 "self": "http://api.example.com/dbnode/dfd6cf2b/health" 429 } 430 } 432 ], 433 "uptime": [ 434 { 435 "componentType": "system", 436 "observedValue": 1209600.245, 437 "observedUnit": "s", 438 "status": "pass", 439 "time": "2018-01-17T03:36:48Z" 440 } 441 ], 442 "cpu:utilization": [ 443 { 444 "componentId": "6fd416e0-8920-410f-9c7b-c479000f7227", 445 "node": 1, 446 "componentType": "system", 447 "observedValue": 85, 448 "observedUnit": "percent", 449 "status": "warn", 450 "time": "2018-01-17T03:36:48Z", 451 "output": "" 452 }, 453 { 454 "componentId": "6fd416e0-8920-410f-9c7b-c479000f7227", 455 "node": 2, 456 "componentType": "system", 457 "observedValue": 85, 458 "observedUnit": "percent", 459 "status": "warn", 460 "time": "2018-01-17T03:36:48Z", 461 "output": "" 462 } 463 ], 464 "memory:utilization": [ 465 { 466 "componentId": "6fd416e0-8920-410f-9c7b-c479000f7227", 467 "node": 1, 468 "componentType": "system", 469 "observedValue": 8.5, 470 "observedUnit": "GiB", 471 "status": "warn", 472 "time": "2018-01-17T03:36:48Z", 473 "output": "" 474 }, 475 { 476 "componentId": "6fd416e0-8920-410f-9c7b-c479000f7227", 477 "node": 2, 478 "componentType": "system", 479 "observedValue": 5500, 480 "observedUnit": "MiB", 481 "status": "pass", 482 "time": "2018-01-17T03:36:48Z", 483 "output": "" 484 } 485 ] 486 }, 487 "links": { 488 "about": "http://api.example.com/about/authz", 489 "http://api.x.io/rel/thresholds": 490 "http://api.x.io/about/authz/thresholds" 491 } 492 } 494 6. Security Considerations 496 Clients need to exercise care when reporting health information. 497 Malicious actors could use this information for orchestrating 498 attacks. In some cases, the health check endpoints may need to be 499 authenticated and institute role-based access control. 501 7. IANA Considerations 503 The media type for health check response is application/health+json. 505 o Media type name: application 507 o Media subtype name: health+json 509 o Required parameters: n/a 511 o Optional parameters: n/a 513 o Encoding considerations: binary 515 o Security considerations: Health+JSON shares security issues common 516 to all JSON content types. See RFC 8259 Section #12 for 517 additional information. 519 Health+JSON allows utilization of Uniform Resource Identifiers 520 (URIs) and as such shares security issues common to URI usage. 521 See RFC 3986 Section #7 for additional information. 523 Since health+json can carry wide variety of data, some data may 524 require privacy or integrity services. This specification does 525 not prescribe any specific solution and assumes that concrete 526 implementations will utilize common, trusted approaches such as 527 TLS/HTTPS, OAuth2 etc. 529 o Interoperability considerations: None 531 o Published specification: this RFC draft 533 o Applications which use this media: Various 535 o Fragment identifier considerations: Health+JSON follows RFC6901 536 for implementing URI Fragment Identification standard to JSON 537 content types. 539 o Restrictions on usage: None 541 o Additional information: 543 1. Deprecated alias names for this type: n/a 545 2. Magic number(s): n/a 547 3. File extension(s): .json 549 4. Macintosh file type code: TEXT 551 5. Object Identifiers: n/a 553 o General Comments: 555 o Person to contact for further information: 557 1. Name: Irakli Nadareishvili 559 2. Email: irakli@gmail.com 561 o Intended usage: Common 563 o Author/Change controller: Irakli Nadareishvili 565 8. Acknowledgements 567 Thanks to Mike Amundsen, Erik Wilde, Justin Bachorik and Randall 568 Randall for their suggestions and feedback. And to Mark Nottingham 569 for blueprint for authoring RFCs easily. 571 9. Creating and Serving Health Responses 573 When making an health check endpoint available, there are a few 574 things to keep in mind: 576 o A health response endpoint is best located at a memorable and 577 commonly-used URI, such as "health" because it will help self- 578 discoverability by clients. 580 o Health check responses can be personalized. For example, you 581 could advertise different URIs, and/or different kinds of link 582 relations, to afford different clients access to additional health 583 check information. 585 o Health check responses SHOULD be assigned a freshness lifetime 586 (e.g., "Cache-Control: max-age=3600") so that clients can 587 determine how long they could cache them, to avoid overly frequent 588 fetching and unintended DDOS-ing of the service. Any method of 589 cache lifetime negotiation provided by HTTP spec is acceptable 590 (e.g. ETags are just fine). 592 o Custom link relation types, as well as the URIs for variables, 593 SHOULD lead to documentation for those constructs. 595 10. Consuming Health Check Responses 597 Clients might use health check responses in a variety of ways. 599 Note that the health check response is a "living" document; links 600 from the health check response MUST NOT be assumed to be valid beyond 601 the freshness lifetime of the health check response, as per HTTP's 602 caching model [RFC7234]. 604 As a result, clients ought to cache the health check response (as per 605 [RFC7234]), to avoid fetching it before every interaction (which 606 would otherwise be required). 608 Likewise, a client encountering a 404 (Not Found) on a link is 609 encouraged to obtain a fresh copy of the health check response, to 610 assure that it is up-to-date. 612 11. References 614 11.1. Normative References 616 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 617 Requirement Levels", BCP 14, RFC 2119, 618 DOI 10.17487/RFC2119, March 1997, 619 . 621 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 622 Resource Identifier (URI): Generic Syntax", STD 66, 623 RFC 3986, DOI 10.17487/RFC3986, January 2005, 624 . 626 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 627 and D. Orchard, "URI Template", RFC 6570, 628 DOI 10.17487/RFC6570, March 2012, 629 . 631 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 632 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 633 RFC 7234, DOI 10.17487/RFC7234, June 2014, 634 . 636 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 637 Interchange Format", STD 90, RFC 8259, 638 DOI 10.17487/RFC8259, December 2017, 639 . 641 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 642 DOI 10.17487/RFC8288, October 2017, 643 . 645 11.2. Informative References 647 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 648 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 649 . 651 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 652 Specifications and Registration Procedures", BCP 13, 653 RFC 6838, DOI 10.17487/RFC6838, January 2013, 654 . 656 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 657 Protocol (HTTP/1.1): Message Syntax and Routing", 658 RFC 7230, DOI 10.17487/RFC7230, June 2014, 659 . 661 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 662 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 663 DOI 10.17487/RFC7231, June 2014, 664 . 666 11.3. URIs 668 [1] https://github.com/inadarei/rfc-healthcheck/issues 670 [2] https://inadarei.github.io/rfc-healthcheck/ 672 [3] https://github.com/inadarei/rfc-healthcheck/commits/master 674 [4] https://datatracker.ietf.org/doc/draft-inadarei-api-health-check/ 676 Author's Address 678 Irakli Nadareishvili 679 114 5th Avenue 680 New York 681 United States of America 683 Email: irakli@gmail.com 684 URI: http://www.freshblurbs.com