One of the pieces of the current solution we aim for is leveraging "partial" result listings through the partial parameter e.g. /jobs/{job_id}/results?partial=true.
However we also require signed URLs through a "canonical" link in /jobs/{job_id}/results, e.g. possibly https://whatever.com/azerty123 (where the azerty123 is an opaque blob that securely can be resolved to the original batch job result listing)
It is not completely clear how the partial=true should be included in the signed URL: should it be encoded automatically in the opaque blob, or should the user add it explicitly, e.g. https://whatever.com/azerty123?partial=true?
I guess it's the former, but we might have to clarify that a bit .
E.g. current description state:
It is strongly recommended to add a link with relation type canonical, which points to this STAC document using a signed URL. This way the STAC metadata can be used by non-openEO clients without additional authentication steps.
e.g.
... which points to this STAC document (including all query parameters like partial) using a signed URL...
I'm working on crossbackend job execution in aggeragtor (https://github.com/Open-EO/openeo-aggregator/issues/115).
One of the pieces of the current solution we aim for is leveraging "partial" result listings through the
partial
parameter e.g./jobs/{job_id}/results?partial=true
. However we also require signed URLs through a "canonical" link in/jobs/{job_id}/results
, e.g. possiblyhttps://whatever.com/azerty123
(where theazerty123
is an opaque blob that securely can be resolved to the original batch job result listing)It is not completely clear how the
partial=true
should be included in the signed URL: should it be encoded automatically in the opaque blob, or should the user add it explicitly, e.g.https://whatever.com/azerty123?partial=true
?I guess it's the former, but we might have to clarify that a bit .
E.g. current description state:
e.g.