You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: specifications/docs/overview/Glossary_and_conventions.md
+5-4Lines changed: 5 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,15 +17,16 @@ Throughout this specification, a set of short terms is being used as described b
17
17
|`uid_based_id`| An abstract identifier: it can take a form of an OBJECT_VERSION_ID identifier taken from VERSION.uid.value (i.e. a `version_uid`), or a form of a HIER_OBJECT_ID identifier taken from VERSIONED_OBJECT.uid.value (i.e. a `versioned_object_uid`). |
18
18
|`preceding_version_uid`| The value of a previous VERSION unique identifier, used usually for PUT or DELETE methods (e.g. 8849182c-82ad-4088-a07f-48ead4180515::openEHRSys.example.com::1) |
19
19
|`version_at_time`| Time specifier used to retrieve the VERSION at a given time; the value is in the extended ISO 8601 format (e.g. 2015-01-20T19:30:22.765+01:00) |
20
-
20
+
<br>
21
21
22
22
### OpenAPI Specification files
23
23
24
24
This openEHR REST specifications can be downloaded as YAML files in [OpenAPI Specification 3.0](https://spec.openapis.org/oas/v3.0.3) format.
25
25
26
26
For each API there are two flavours provided:
27
-
- a file optimized for code generators, with the file name having the `-codegen.openapi.yaml`; this file can be used with tools like [OpenAPI Generator](https://github.com/openapitools/openapi-generator), or [Swagger codegen](https://github.com/swagger-api/swagger-codegen),
28
-
- a file optimized for data validation, with the file name having the `-codegen.openapi.yaml`; this file can be used by (mock-)servers or applications to validate openEHR request and response payloads.
29
-
The main difference between these files (aside of schema model names) is that the codegen flavour is defining and using inheritance in model schemas, with the use of `allOf` property and discriminators (see [Polymorphism](https://spec.openapis.org/oas/v3.0.3#composition-and-inheritance-polymorphism)), whereas the validation variant is flattening all these requirements (each model contains all RM-inherited properties).
27
+
- a file optimized for code generators, with the file name having the `-codegen.openapi.yaml` suffix; this file can be used with tools like [OpenAPI Generator](https://github.com/openapitools/openapi-generator), or [Swagger codegen](https://github.com/swagger-api/swagger-codegen),
28
+
- a file optimized for data validation, with the file name having the `-codegen.openapi.yaml` suffix; this file can be used by (mock-)servers or applications to validate openEHR request and response payloads.
29
+
30
+
The main difference between these files (aside of schema model names) is that the codegen flavour is defining and using inheritance in model schemas, with the use of `allOf` property and discriminators, whereas the validation variant is flattening all these requirements (each model contains all RM-inherited properties), and is using `oneOf` property to define union-types. See [Polymorphism](https://spec.openapis.org/oas/v3.0.3#composition-and-inheritance-polymorphism) specification.
30
31
31
32
The latest OpenAPI Specification files are available in GitHub at [openEHR/specifications-ITS-REST/computable/OAS](https://github.com/openEHR/specifications-ITS-REST/tree/master/computable/OAS).
Copy file name to clipboardExpand all lines: specifications/docs/overview/Resources.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -67,7 +67,7 @@ These formats and their associated negotiation protocol is described below.
67
67
When resources representation is serialized as XML, the request payload as well as the result MUST be valid against [published XSDs](https://specifications.openehr.org/releases/ITS-XML/latest).
68
68
69
69
A client MAY use the header `Content-Type: application/xml` in the requests to specify the XML payload format.
70
-
If the service cannot process the request payload as XML format is not supported, it MUST respond with HTTP status code`415 Unsupported Media Type`.
70
+
If the service cannot process the request payload as XML format is not supported, it MUST respond with HTTP status code`415 Unsupported Media Type`.
71
71
72
72
The client SHOULD use the `Accept: application/xml` request header in order to specify the expected XML response format.
73
73
If the service cannot fulfill this aspect of the request, it MUST respond with HTTP status code `406 Not Acceptable`.
@@ -168,7 +168,7 @@ and the [TDD2canonical](https://github.com/openEHR/openEHR-TDD2canonical) projec
168
168
Current alternative formats might not be supported once they become obsolete or superseded by newer formats.
169
169
170
170
A client MAY use the header `Content-Type` in the requests to specify the simplified payload format.
171
-
If the service cannot process the request payload as the simplified format is not supported, it MUST respond with HTTP status code`415 Unsupported Media Type`.
171
+
If the service cannot process the request payload as the simplified format is not supported, it MUST respond with HTTP status code`415 Unsupported Media Type`.
172
172
173
173
The client SHOULD use the `Accept` request header in order to specify the expected simplified response format.
174
174
If the service cannot fulfill this aspect of the request, it MUST respond with HTTP status code `406 Not Acceptable`.
0 commit comments