Add "OpenEO-Identifier" header to synchronous processing response (#533)

* Add "OpenEO-Identifier" header to synchronous processing response

* Update openapi.yaml

Co-authored-by: Matthias Mohr <matthias@mohr.ws>

---------

Co-authored-by: Matthias Mohr <m.mohr@uni-muenster.de>
Co-authored-by: Matthias Mohr <matthias@mohr.ws>

Author: soxofaan

CHANGELOG.md

@@ -11,10 +11,11 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - **New extensions:**
   - [Remote Process Definition Extension](./extensions/remote-process-definition/README.md)
 - Added `version` property to `GET /processes` [#517](https://github.com/Open-EO/openeo-api/issues/517)
+- `POST /result`: Added response header "OpenEO-Identifier" to expose an identifier associated with a synchronous processing request.
 
 ### Fixed
 
-- `GET /file_formats`: Base paramater on top of normal JSON Schema, not Process JSON Schema
+- `GET /file_formats`: Base parameter on top of normal JSON Schema, not Process JSON Schema
 - `PATCH /services/{service_id}` and `PATCH /jobs/{job_id}`: Explicitly allow updating back-end specific properties (as in `POST`)
 - `GET /services/{service_id}` and `GET /jobs/{job_id}`: Explicitly allow listing back-end specific properties (as provided in `POST`)
 - `GET /jobs/{job_id}/results`: Clarify that signed URLs (used as "canonical" link) should be regenerated each time.

openapi.yaml

@@ -2261,6 +2261,12 @@ paths:
               description: MAY include the costs for processing and downloading the data.
               schema:
                 $ref: '#/components/schemas/money'
+            OpenEO-Identifier:
+              description: Optionally, an identifier associated with the synchronous processing request.
+              schema:
+                type: string
+                pattern: '^[\w\-\.~]+$'
+                example: a3cca2b2aa1e3b5b
             Link:
               description: >-
                 The header MAY indicate a link to a log file generated by the request. If provided, the link MUST be serialized according to [RFC 8288](https://www.rfc-editor.org/rfc/rfc8288.html#section-3) and MUST use the relation type `monitor`. The link MUST follow the specifications for the links `GET /jobs/{job_id}/logs` and `GET /services/{service_id}/logs`, except that is MUST NOT accept any parameters (limit/offset). Therefore, the link MUST be accessible with HTTP GET, MUST be secured using a Bearer token and MUST follow the corresponding request body schema.