Authorization of /validation

[soxofaan]

openeo-api/openapi.yaml

Lines 2195 to 2229 in 1247172

	/validation:
	post:
	summary: Validate a user-defined process (graph)
	operationId: validate-custom-process
	description: >-
	Validates a process graph without executing it. A process graph is
	considered valid unless the `errors` array in the response contains at
	least one error.
	Checks whether the process graph is schematically correct and the
	processes are supported by the back-end. It MUST also checks the
	parameter values against the schema, but checking whether the values are
	adequate in the context of data is OPTIONAL. For example, a non-existing
	band name may may get rejected only by a few back-ends.
	Errors that usually occur during processing MAY NOT get reported, e.g.
	if a referenced file is accessible at the time of execution.
	Back-ends can either report all errors at once or stop the validation
	once they found the first error.
	Please note that a validation always returns with HTTP status code 200.
	Error codes in the 4xx and 5xx ranges MUST be returned only when the
	general validation request is invalid (e.g. server is busy or no process
	graph parameter specified), but never if the process graph validation
	found an error (e.g. an unsupported process).
	tags:
	- User-Defined Processes
	security:
	- {}
	- Bearer: []

is it intended that /validation can also be requested without authorization?

[m-mohr]

Yes, we thought it's helpful if users could validate and check whether the back-end is capable of running their stuff without registering and all the hassle.

[soxofaan]

ok make sense.

One minor thing is that /validation is currently only under category User-Defined Processes while from your reply I understand it is about validation of complete process graphs (as well). They are very much alike, but not completely: e.g. in a UDP it is fine to have unresolved parameters, while in a complete process graph you don't want that, which could be a relevant validation aspect.

[m-mohr]

Hmm, I now realized it's not clear from the description what to do with unresolved parameters. I'd argue that unresolved parameters shouldn't lead to an error (and thus it's in this category). Setting the parameters etc seems to me more fitting into submitting the batch job/service/...

We should clarify that. If we wan't to check for unresolved parameters, I'd guess the best idea is adding a parameter to the request?

[soxofaan]

Well my question is also: if it's only about UDPs, is /validation the best url for that, as all the other UDP urls start with /process_graphs?

[m-mohr]

There are some things to consider:

1. The processes you send to batch jobs/services/... are still UDP techically. There's very little difference schema-wise (just in metadata).
2. /process_graphs/validation doesn't work due to the conflict with the id parameter
3. I'm not very happy with the legacy /process_graphs anymore anyway. It seems you are neither: Unification of /processes and /process_graphs #310
4. If we want to add validation including unresolved parameters, a simple backward compatible path parameter could be added.

So I think it's still reasonable to just call it /validation.

[soxofaan]

ok, so to conclude: the /validation endpoint is not only about UDPs in the sense of the named "user defined processes" with a life cycle (storage and retrieval), but also one-off "anonymous" process graphs (e.g. for batch jobs).
Shouldn't /validation then also be tagged under the generic tag "Data processing"?

I'm totally fine with adding parameters to /validation to fine-tune the validation mode/strategy. In VITO backend we haven't implemented it so far, so we don't have practical insights here.

[m-mohr]

Made the changes in PR #316