Revoke signed URLs #341

[m-mohr]

Proposal for issue #341.

Please note that this endpoint could also be used for other functions in the future, that's why there is the specific requirement to send a specific command (i.e. assets = null) to the back-end to indicate that it should revoke access to assets.

This is more an idea for now, but would like to get feedback on the idea.

[soxofaan]

Proposed commit looks fine.

some thoughts:

• PATCHing assets to null might also be used to remove batch job result files from the backend (e.g. to reduce your storage bill without removing batch job metadata)
• What if the backend does not support invalidating urls, e.g. because the (third party) storage solution does not support it? Should the backend then not support PATCH .../results (through the capabilities doc), or should it throw an error (e.g.FeatureUnsupported)?

[m-mohr]

• PATCHing assets to null might also be used to remove batch job result files from the backend (e.g. to reduce your storage bill without removing batch job metadata)

That would still be possible. assets: null is not allowed in STAC so we can use it for this special behavior. To actually remove assets, you'd send assets: {} (i.e. empty object) to be STAC-compliant.

• What if the backend does not support invalidating urls, e.g. because the (third party) storage solution does not support it? Should the backend then not support PATCH .../results (through the capabilities doc), or should it throw an error (e.g.FeatureUnsupported)?

Endpoints in general should not be listed in the capabilities so that clients don't request them. Whether back-ends return a 501 or 404 or something else in the 4xx or 5xx range, if clients request the endpoint anyway is mostly up to them.
You'd be required to send a FeatureUnsupported though if you can e.g. do the asset removal (empty object), but not the asset renewal (null) and a client requests the renewal.

[soxofaan]

assets = null to revoke all previously generated signed URLs
To actually remove assets, you'd send assets: {}

To be honest, this looks quite cryptic and somewhat ad-hoc to me

[m-mohr]

Indeed, looking at it after a while makes it look weird. Maybe a specific HTTP header or a separate HTTP endpoint (although an issue with REST conventions) are better options.