Clarified the behaviour of federation:backends for POST /validation (Open-EO#552)

* Clarified the behaviour of `federation:backends` for `POST /validation`

* Update extensions/federation/README.md

Co-authored-by: Stefaan Lippens <soxofaan@users.noreply.github.com>

---------

Co-authored-by: Stefaan Lippens <soxofaan@users.noreply.github.com>

Author: m-mohr

CHANGELOG.md

@@ -19,6 +19,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - `GET /services/{service_id}` and `GET /jobs/{job_id}`: Explicitly allow listing back-end specific properties (as provided in `POST`)
 - Clarified for log levels which default values apply
 - Clarified how the relation types `license`, `version-history` and `author` can be used to enrich the process metadata. [#531](https://github.com/Open-EO/openeo-api/issues/531)
+- Clarified the behaviour of `federation:backends` for `POST /validation`
 
 ## [1.2.0] - 2021-05-25
 

extensions/federation/README.md

@@ -164,11 +164,11 @@ Every discoverable resource that is defined as an object and allows to contain a
 - `GET /file_formats` (per file format)
 - `GET /service_types` (per service)
 - `GET /udf_runtimes` (per UDF runtime, per version)
-- `POST /validation` (the back-ends that can run the process)
+- `POST /validation` (the back-ends that can run the process, see below)
 - `GET /process_graphs/{id}`
 - `GET /jobs/{job_id}` (the back-ends that generated the result)
 - `GET /jobs/{job_id}/results` (the back-ends that generated the result)
-- `GET /services/{id}`
+- `GET /services/{id}` (the back-ends that host the service)
 
 This can also be embedded deeply into a hierarchical structure, e.g. for process or file format parameters.
 
@@ -189,6 +189,18 @@ schema:
 
 **Note:** In Collections this should generally be provided on the top-level of the object.
 
+### Validation
+
+If this property is returned through the `POST /validation` endpoint, it has the meaning as listed below.
+This also covers the case where the federation supports splitting a process into pieces so that different parts can run on different back-ends.
+
+- Endpoint returns *without* errors:
+  - `federation:backends` is included in the response: The listed back-ends support the workflow (either partially if splitting is supported, or in full).
+  - `federation:backends` is *not* included in the response: At least one of the back-ends support the workflow.
+- Endpoint returns errors:
+  - `federation:backends` is included in the response: The listed back-ends were checked and none of the back-ends can run the workflow as is (neither splitted if supported, nor in full).
+  - `federation:backends` is *not* included in the response: the workflow could not be validated successfully by any of the back-ends or the federation component itself.
+
 ### Examples
 
 #### Process