application/fhir+ndjson
. Currently, NDJSON
SHALL be supported, though servers MAY also support other output formats. Servers SHALL support the full content type of application/fhir+ndjson
as well as abbreviated representations including application/ndjson
and ndjson
.
application/fhir+ndjson
. The Data Provider SHALL support Newline Delimited JSON
, but MAY choose to support additional output formats. The Data Provider SHALL accept the full content type of application/fhir+ndjson
as well as the abbreviated representations application/ndjson
and ndjson
.
Links: Table of Contents | QA Report | Version History |
|
Propose a change
Retry-After
header with a delay time in seconds (for example, 120
to represent two minutes) or an HTTP-date (for example, Fri, 31 Dec 1999 23:59:59 GMT
). When provided, clients SHOULD use this information to inform the timing of future polling requests. The server SHOULD keep an accounting of status queries received from a given client, and if a client is polling too frequently, the server SHOULD respond with a 429 Too Many Requests
status code in addition to a Retry-After
header, and optionally a FHIR OperationOutcome
resource with further explanation. If excessively frequent status queries persist, the server MAY return a 429 Too Many Requests
status code and terminate the session. Other standard HTTP 4XX
and 5XX
status codes MAY be used to identify errors as mentioned below.
Retry-After
header with a delay time in seconds (for example, 120
to represent two minutes) or an HTTP-date (for example, Fri, 31 Dec 1999 23:59:59 GMT
). When provided, clients SHOULD use this information to inform the timing of future polling requests. The server SHOULD keep an accounting of status queries received from a given client, and if a client is polling too frequently, the server SHOULD respond with a 429 Too Many Requests
status code in addition to a Retry-After
header, and optionally a FHIR OperationOutcome
resource with further explanation. If excessively frequent status queries persist, the server MAY return a 429 Too Many Requests
status code and terminate the session. Other standard HTTP 4XX
and 5XX
status codes MAY be used to identify errors as mentioned below.
429 Too Many Requests
status and a
Retry-After
header, following the rate-limiting advice for "Bulk Data Status Request" below.
Retry-After
header with a delay time in seconds (e.g., 120
to represent two minutes) or an HTTP-date (e.g., Fri, 31 Dec 1999 23:59:59 GMT
). When provided, Data Consumers SHOULD use this information to inform the timing of future polling requests. The Data Provider SHOULD keep an accounting of status queries received from a given Data Consumer, and if a Data Consumer is polling too frequently, the Data Provider SHOULD respond with a 429 Too Many Requests
status code in addition to a Retry-After
header, and optionally a FHIR OperationOutcome
resource with further explanation. If excessively frequent status queries persist, the Data Provider MAY return a 429 Too Many Requests
status code and terminate the session. Other standard HTTP 4XX
and 5XX
status codes may be used to identify errors as mentioned below.
Retry-After
header with a delay time in seconds (e.g., 120
to represent two minutes) or an HTTP-date (e.g., Fri, 31 Dec 1999 23:59:59 GMT
). When provided, Data Consumers SHOULD use this information to inform the timing of future polling requests. The Data Provider SHOULD keep an accounting of status queries received from a given Data Consumer, and if a Data Consumer is polling too frequently, the Data Provider SHOULD respond with a 429 Too Many Requests
status code in addition to a Retry-After
header, and optionally a FHIR OperationOutcome
resource with further explanation. If excessively frequent status queries persist, the Data Provider MAY return a 429 Too Many Requests
status code and terminate the session. Other standard HTTP 4XX
and 5XX
status codes may be used to identify errors as mentioned below.
Retry-After
header with a delay time in seconds (for example, 120
to represent two minutes) or an HTTP-date (for example, Fri, 31 Dec 1999 23:59:59 GMT
). When provided, Data Providers SHOULD use this information to inform the timing of future polling requests. The Data Consumer SHOULD keep an accounting of status queries received from a given Data Provider, and if a Data Provider is polling too frequently, the Data Consumer SHOULD respond with a 429 Too Many Requests
status code in addition to a Retry-After
header, and optionally a FHIR OperationOutcome
resource with further explanation. If excessively frequent status queries persist, the Data Consumer MAY return a 429 Too Many Requests
status code and terminate the session. Other standard HTTP 4XX
and 5XX
status codes MAY be used to identify errors as mentioned below.
Retry-After
header with a delay time in seconds (for example, 120
to represent two minutes) or an HTTP-date (for example, Fri, 31 Dec 1999 23:59:59 GMT
). When provided, Data Providers SHOULD use this information to inform the timing of future polling requests. The Data Consumer SHOULD keep an accounting of status queries received from a given Data Provider, and if a Data Provider is polling too frequently, the Data Consumer SHOULD respond with a 429 Too Many Requests
status code in addition to a Retry-After
header, and optionally a FHIR OperationOutcome
resource with further explanation. If excessively frequent status queries persist, the Data Consumer MAY return a 429 Too Many Requests
status code and terminate the session. Other standard HTTP 4XX
and 5XX
status codes MAY be used to identify errors as mentioned below.
