idnits 2.17.1 draft-inadarei-api-health-check-03.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 (May 9, 2019) is 1811 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 656 -- Looks like a reference, but probably isn't: '2' on line 658 -- Looks like a reference, but probably isn't: '3' on line 660 -- Looks like a reference, but probably isn't: '4' on line 662 == Unused Reference: 'RFC6838' is defined on line 639, 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 May 9, 2019 4 Intended status: Informational 5 Expires: November 10, 2019 7 Health Check Response Format for HTTP APIs 8 draft-inadarei-api-health-check-03 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 November 10, 2019. 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 5. Example Output . . . . . . . . . . . . . . . . . . . . . . . 8 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 92 9. Creating and Serving Health Responses . . . . . . . . . . . . 12 93 10. Consuming Health Check Responses . . . . . . . . . . . . . . 13 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 95 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 96 11.2. Informative References . . . . . . . . . . . . . . . . . 14 97 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 100 1. Introduction 102 The vast majority of modern APIs driving data to web and mobile 103 applications use HTTP [RFC7230] as their protocol. The health and 104 uptime of these APIs determine availability of the applications 105 themselves. In distributed systems built with a number of APIs, 106 understanding the health status of the APIs and making corresponding 107 decisions, for caching, failover or circuit-breaking, are essential 108 to the ability of providing highly-available solutions. 110 There exists a wide variety of operational software that relies on 111 the ability to read health check response of APIs. However, there is 112 currently no standard for the health check output response, so most 113 applications either rely on the basic level of information included 114 in HTTP status codes [RFC7231] or use task-specific formats. 116 Usage of task-specific or application-specific formats creates 117 significant challenges, disallowing any meaningful interoperability 118 across different implementations and between different tooling. 120 Standardizing a format for health checks can provide any of a number 121 of benefits, including: 123 o Flexible deployment - since operational tooling and API clients 124 can rely on rich, uniform format, they can be safely combined and 125 substituted as needed. 127 o Evolvability - new APIs, conforming to the standard, can safely be 128 introduced in any environment and ecosystem that also conforms to 129 the same standard, without costly coordination and testing 130 requirements. 132 This document defines a "health check" format using the JSON format 133 [RFC8259] for APIs to use as a standard point for the health 134 information they offer. Having a well-defined format for this 135 purpose promotes good practice and tooling. 137 2. Notational Conventions 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 3. API Health Response 145 Health Check Response Format for HTTP APIs uses the JSON format 146 described in [RFC8259] and has the media type "application/ 147 health+json". 149 Its content consists of a single mandatory root field ("status") and 150 several optional fields: 152 3.1. status 154 status: (required) indicates whether the service status is acceptable 155 or not. API publishers SHOULD use following values for the field: 157 o "pass": healthy (acceptable aliases: "ok" to support Node's 158 Terminus and "up" for Java's SpringBoot), 160 o "fail": unhealthy (acceptable aliases: "error" to support Node's 161 Terminus and "down" for Java's SpringBoot), and 163 o "warn": healthy, with some concerns. 165 The value of the status field is case-insensitive and is tightly 166 related with the HTTP response code returned by the health endpoint. 167 For "pass" status, HTTP response code in the 2xx-3xx range MUST be 168 used. For "fail" status, HTTP response code in the 4xx-5xx range 169 MUST be used. In case of the "warn" status, endpoints MUST return 170 HTTP status in the 2xx-3xx range, and additional information SHOULD 171 be provided, utilizing optional fields of the response. 173 A health endpoint is only meaningful in the context of the component 174 it indicates the health of. It has no other meaning or purpose. As 175 such, its health is a conduit to the health of the component. 176 Clients SHOULD assume that the HTTP response code returned by the 177 health endpoint is applicable to the entire component (e.g. a larger 178 API or a microservice). This is compatible with the behavior that 179 current infrastructural tooling expects: load-balancers, service 180 discoveries and others, utilizing health-checks. 182 3.2. version 184 version: (optional) public version of the service. 186 3.3. releaseId 188 releaseId: (optional) in well-designed APIs, backwards-compatible 189 changes in the service should not update a version number. APIs 190 usually change their version number as infrequently as possible, to 191 preserve stable interface. However, implementation of an API may 192 change much more frequently, which leads to the importance of having 193 separate "release number" or "releaseId" that is different from the 194 public version of the API. 196 3.4. notes 198 notes: (optional) array of notes relevant to current state of health 200 3.5. output 202 output: (optional) raw error output, in case of "fail" or "warn" 203 states. This field SHOULD be omitted for "pass" state. 205 3.6. checks 207 checks (optional) is an object that provides detailed health statuses 208 of additional downstream systems and endpoints which can affect the 209 overall health of the main API. Please refer to the "The Checks 210 Object" section for more information. 212 3.7. links 214 links (optional) is an array of objects containing link relations and 215 URIs [RFC3986] for external links that MAY contain more information 216 about the health of the endpoint. Per web-linking standards 217 [RFC8288] a link relationship SHOULD either be a common/registered 218 one or be indicated as a URI, to avoid name clashes. If a "self" 219 link is provided, it MAY be used by clients to check health via HTTP 220 response code, as mentioned above. 222 3.8. serviceId 224 serviceId (optional) is a unique identifier of the service, in the 225 application scope. 227 3.9. description 229 description (optional) is a human-friendly description of the 230 service. 232 4. The Checks Object 234 The "checks" object MAY have a number of unique keys, one for each 235 logical downstream dependency or sub-component. Since each sub- 236 component may be backed by several nodes with varying health 237 statuses, these keys point to arrays of objects. In case of a 238 single-node sub-component (or if presence of nodes is not relevant), 239 a single-element array SHOULD be used as the value, for consistency. 241 The key identifying an element in the object SHOULD be a unique 242 string within the details section. It MAY have two parts: 243 "{componentName}:{measurementName}", in which case the meaning of the 244 parts SHOULD be as follows: 246 o componentName: (optional) human-readable name for the component. 247 MUST not contain a colon, in the name, since colon is used as a 248 separator. 250 o measurementName: (optional) name of the measurement type (a data 251 point type) that the status is reported for. MUST not contain a 252 colon, in the name, since colon is used as a separator. The 253 observation's name can be one of: 255 * A pre-defined value from this spec. Pre-defined values 256 include: 258 + utilization 260 + responseTime 262 + connections 264 + uptime 266 * A common and standard term from a well-known source such as 267 schema.org, IANA or microformats. 269 * A URI that indicates extra semantics and processing rules that 270 MAY be provided by a resource at the other end of the URI. 271 URIs do not have to be dereferenceable, however. They are just 272 a namespace, and the meaning of a namespace CAN be provided by 273 any convenient means (e.g. publishing an RFC, Swagger document 274 or a nicely printed book). 276 On the value side of the equation, each "component details" object in 277 the array MAY have one of the following object keys: 279 4.1. componentId 281 componentId: (optional) is a unique identifier of an instance of a 282 specific sub-component/dependency of a service. Multiple objects 283 with the same componentID MAY appear in the details, if they are from 284 different nodes. 286 4.2. componentType 288 componentType: (optional) SHOULD be present if componentName is 289 present. It's a type of the component and could be one of: 291 o Pre-defined value from this spec. Pre-defined values include: 293 * component 295 * datastore 297 * system 299 o A common and standard term from a well-known source such as 300 schema.org, IANA or microformats. 302 o A URI that indicates extra semantics and processing rules that MAY 303 be provided by a resource at the other end of the URI. URIs do 304 not have to be dereferenceable, however. They are just a 305 namespace, and the meaning of a namespace CAN be provided by any 306 convenient means (e.g. publishing an RFC, Swagger document or a 307 nicely printed book). 309 4.3. observedValue 311 observedValue: (optional) could be any valid JSON value, such as: 312 string, number, object, array or literal. 314 4.4. observedUnit 316 observedUnit (optional) SHOULD be present if observedValue is 317 present. Clarifies the unit of measurement in which observedUnit is 318 reported, e.g. for a time-based value it is important to know whether 319 the time is reported in seconds, minutes, hours or something else. 320 To make sure unit is denoted by a well-understood name or an 321 abbreviation, it SHOULD be one of: 323 o A common and standard term from a well-known source such as 324 schema.org, IANA, microformats, or a standards document such as 325 [RFC3339]. 327 o A URI that indicates extra semantics and processing rules that MAY 328 be provided by a resource at the other end of the URI. URIs do 329 not have to be dereferenceable, however. They are just a 330 namespace, and the meaning of a namespace CAN be provided by any 331 convenient means (e.g. publishing an RFC, Swagger document or a 332 nicely printed book). 334 4.5. status 336 status (optional) has the exact same meaning as the top-level 337 "output" element, but for the sub-component/downstream dependency 338 represented by the details object. 340 4.6. affectedEndpoints 342 A typical API has many URI endpoints. Most of the time we are 343 interested in the overall health of the API, without diving into 344 details. That said, sometimes operational and resilience middleware 345 needs to know more details about the health of the API (which is why 346 "checks" property provides details). In such cases, we often need to 347 indicate which particular endpoints are affected by a particular 348 check's troubles vs. other endpoints that may be fine. The 349 "affectedEndpoints" property is a JSON array containing URI Templates 350 as defined by [RFC6570]. 352 4.7. time 354 time (optional) is the date-time, in ISO8601 format, at which the 355 reading of the observedValue was recorded. This assumes that the 356 value can be cached and the reading typically doesn't happen in real 357 time, for performance and scalability purposes. 359 4.8. output 361 output (optional) has the exact same meaning as the top-level 362 "output" element, but for the sub-component/downstream dependency 363 represented by the details object. 365 4.9. links 367 links (optional) has the exact same meaning as the top-level "output" 368 element, but for the sub-component/downstream dependency represented 369 by the details object. 371 5. Example Output 373 GET /health HTTP/1.1 374 Host: example.org 375 Accept: application/health+json 377 HTTP/1.1 200 OK 378 Content-Type: application/health+json 379 Cache-Control: max-age=3600 380 Connection: close 382 { 383 "status": "pass", 384 "version": "1", 385 "releaseId": "1.2.2", 386 "notes": [""], 387 "output": "", 388 "serviceId": "f03e522f-1f44-4062-9b55-9587f91c9c41", 389 "description": "health of authz service", 390 "checks": { 391 "cassandra:responseTime": [ 392 { 393 "componentId": "dfd6cf2b-1b6e-4412-a0b8-f6f7797a60d2", 394 "componentType": "datastore", 395 "observedValue": 250, 396 "observedUnit": "ms", 397 "status": "pass", 398 "affectedEndpoints" : [ 399 "/users/{userId}", 400 "/customers/{customerId}/status", 401 "/shopping/{anything}" 402 ], 403 "time": "2018-01-17T03:36:48Z", 404 "output": "" 405 } 406 ], 407 "cassandra:connections": [ 408 { 409 "componentId": "dfd6cf2b-1b6e-4412-a0b8-f6f7797a60d2", 410 "type": "datastore", 411 "observedValue": 75, 412 "status": "warn", 413 "time": "2018-01-17T03:36:48Z", 414 "output": "", 415 "links": { 416 "self": "http://api.example.com/dbnode/dfd6cf2b/health" 417 } 418 } 419 ], 420 "uptime": [ 421 { 422 "componentType": "system", 423 "observedValue": 1209600.245, 424 "observedUnit": "s", 425 "status": "pass", 426 "time": "2018-01-17T03:36:48Z" 427 } 428 ], 429 "cpu:utilization": [ 430 { 431 "componentId": "6fd416e0-8920-410f-9c7b-c479000f7227", 432 "node": 1, 433 "componentType": "system", 434 "observedValue": 85, 435 "observedUnit": "percent", 436 "status": "warn", 437 "time": "2018-01-17T03:36:48Z", 438 "output": "" 439 }, 440 { 441 "componentId": "6fd416e0-8920-410f-9c7b-c479000f7227", 442 "node": 2, 443 "componentType": "system", 444 "observedValue": 85, 445 "observedUnit": "percent", 446 "status": "warn", 447 "time": "2018-01-17T03:36:48Z", 448 "output": "" 449 } 450 ], 451 "memory:utilization": [ 452 { 453 "componentId": "6fd416e0-8920-410f-9c7b-c479000f7227", 454 "node": 1, 455 "componentType": "system", 456 "observedValue": 8.5, 457 "observedUnit": "GiB", 458 "status": "warn", 459 "time": "2018-01-17T03:36:48Z", 460 "output": "" 461 }, 462 { 463 "componentId": "6fd416e0-8920-410f-9c7b-c479000f7227", 464 "node": 2, 465 "componentType": "system", 466 "observedValue": 5500, 467 "observedUnit": "MiB", 468 "status": "pass", 469 "time": "2018-01-17T03:36:48Z", 470 "output": "" 471 } 472 ] 473 }, 474 "links": { 475 "about": "http://api.example.com/about/authz", 476 "http://api.x.io/rel/thresholds": 477 "http://api.x.io/about/authz/thresholds" 479 } 480 } 482 6. Security Considerations 484 Clients need to exercise care when reporting health information. 485 Malicious actors could use this information for orchestrating 486 attacks. In some cases, the health check endpoints may need to be 487 authenticated and institute role-based access control. 489 7. IANA Considerations 491 The media type for health check response is application/health+json. 493 o Media type name: application 495 o Media subtype name: health+json 497 o Required parameters: n/a 499 o Optional parameters: n/a 501 o Encoding considerations: binary 503 o Security considerations: Health+JSON shares security issues common 504 to all JSON content types. See RFC 8259 Section #12 for 505 additional information. 507 Health+JSON allows utilization of Uniform Resource Identifiers 508 (URIs) and as such shares security issues common to URI usage. 509 See RFC 3986 Section #7 for additional information. 511 Since health+json can carry wide variety of data, some data may 512 require privacy or integrity services. This specification does 513 not prescribe any specific solution and assumes that concrete 514 implementations will utilize common, trusted approaches such as 515 TLS/HTTPS, OAuth2 etc. 517 o Interoperability considerations: None 519 o Published specification: this RFC draft 521 o Applications which use this media: Various 523 o Fragment identifier considerations: Health+JSON follows RFC6901 524 for implementing URI Fragment Identification standard to JSON 525 content types. 527 o Restrictions on usage: None 529 o Additional information: 531 1. Deprecated alias names for this type: n/a 533 2. Magic number(s): n/a 535 3. File extension(s): .json 537 4. Macintosh file type code: TEXT 539 5. Object Identifiers: n/a 541 o General Comments: 543 o Person to contact for further information: 545 1. Name: Irakli Nadareishvili 547 2. Email: irakli@gmail.com 549 o Intended usage: Common 551 o Author/Change controller: Irakli Nadareishvili 553 8. Acknowledgements 555 Thanks to Mike Amundsen, Erik Wilde, Justin Bachorik and Randall 556 Randall for their suggestions and feedback. And to Mark Nottingham 557 for blueprint for authoring RFCs easily. 559 9. Creating and Serving Health Responses 561 When making an health check endpoint available, there are a few 562 things to keep in mind: 564 o A health response endpoint is best located at a memorable and 565 commonly-used URI, such as "health" because it will help self- 566 discoverability by clients. 568 o Health check responses can be personalized. For example, you 569 could advertise different URIs, and/or different kinds of link 570 relations, to afford different clients access to additional health 571 check information. 573 o Health check responses SHOULD be assigned a freshness lifetime 574 (e.g., "Cache-Control: max-age=3600") so that clients can 575 determine how long they could cache them, to avoid overly frequent 576 fetching and unintended DDOS-ing of the service. Any method of 577 cache lifetime negotiation provided by HTTP spec is acceptable 578 (e.g. ETags are just fine). 580 o Custom link relation types, as well as the URIs for variables, 581 should lead to documentation for those constructs. 583 10. Consuming Health Check Responses 585 Clients might use health check responses in a variety of ways. 587 Note that the health check response is a "living" document; links 588 from the health check response MUST NOT be assumed to be valid beyond 589 the freshness lifetime of the health check response, as per HTTP's 590 caching model [RFC7234]. 592 As a result, clients ought to cache the health check response (as per 593 [RFC7234]), to avoid fetching it before every interaction (which 594 would otherwise be required). 596 Likewise, a client encountering a 404 (Not Found) on a link is 597 encouraged to obtain a fresh copy of the health check response, to 598 assure that it is up-to-date. 600 11. References 602 11.1. Normative References 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, 606 DOI 10.17487/RFC2119, March 1997, 607 . 609 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 610 Resource Identifier (URI): Generic Syntax", STD 66, 611 RFC 3986, DOI 10.17487/RFC3986, January 2005, 612 . 614 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 615 and D. Orchard, "URI Template", RFC 6570, 616 DOI 10.17487/RFC6570, March 2012, 617 . 619 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 620 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 621 RFC 7234, DOI 10.17487/RFC7234, June 2014, 622 . 624 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 625 Interchange Format", STD 90, RFC 8259, 626 DOI 10.17487/RFC8259, December 2017, 627 . 629 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 630 DOI 10.17487/RFC8288, October 2017, 631 . 633 11.2. Informative References 635 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 636 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 637 . 639 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 640 Specifications and Registration Procedures", BCP 13, 641 RFC 6838, DOI 10.17487/RFC6838, January 2013, 642 . 644 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 645 Protocol (HTTP/1.1): Message Syntax and Routing", 646 RFC 7230, DOI 10.17487/RFC7230, June 2014, 647 . 649 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 650 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 651 DOI 10.17487/RFC7231, June 2014, 652 . 654 11.3. URIs 656 [1] https://github.com/inadarei/rfc-healthcheck/issues 658 [2] https://inadarei.github.io/rfc-healthcheck/ 660 [3] https://github.com/inadarei/rfc-healthcheck/commits/master 662 [4] https://datatracker.ietf.org/doc/draft-inadarei-api-health-check/ 664 Author's Address 665 Irakli Nadareishvili 666 114 5th Avenue 667 New York 668 United States 670 Email: irakli@gmail.com 671 URI: http://www.freshblurbs.com