Data response type
Data response structure
Headers All header fields defined here in the Data-response are mandatory. Apart from these custom headers can be added which the network can agree upon:
req-id An id of the data request for which this response is.
schema-name The schema name of the data-response. This is to identify the schema provided by the network. For a collision free naming we suggest to have the schema name of the format <gateway-prefix>.<schema-name>
schema-version The schema version identifier.
content-type The content-type of the data-response body. This can be of the form text/json, text/xml, application/pdf, image/jpeg etc.. This is similar to the Content-Type header defined in the RFC 7231.
body-encrypted Tell if the body of the response is encrypted.
key The key used to encrypt the body. This is in JWK format.
multi-part Is this a multi part response.
part-no Sequence no of the part which is fetched.
total-parts Total no of parts which are available.
total-size-in-bytes Size of the total data to be shared.
part-size-in-bytes Size of the data shared.
Body This is the data which gets shared
Signature The signature of data-response in the JWS format.
For the above data type the PDP can provide the response in any of the defined content types, like text/JSON would give the txn details in the JSON format and application/pdf would share the txn details in the pdf format. It is suggested that PDP model their systems to provide the results in text/JSON or text/xml format as they are more machine friendly. Some data types may or may not support application/pdf, image/png etc for backward compatibility.
Similarly in the case of health domain FHIR data exchange standards are accepted internationally and can be used as data type with DEPA.