Support specification of presigned/non-presigned URLs on put_urls

[j616]

Details

• Adds the ability to explicitly select the use of pre-signed put_urls.
• Adds the ability to explicitly signal where put_urls are pre-signed or not
• Additional clarity on the authentication methods used by put_urls and get_urls

Issue (if relevant)

GitHub Issue: #221
Jira ticket: https://jira.dev.bbc.co.uk/browse/CLOUDFIT-5588

Related PRs

Submitter PR Checks

• PR completes task/fixes bug
• API version has been incremented if necessary
• ADR status has been updated, and ADR implementation has been recorded
• Documentation updated (README, etc.)
• PR added to Jira Issue (if relevant)
• Follow-up stories added to Jira

Reviewer PR Checks

• PR completes task/fixes bug
• Design makes sense, and fits with our current code base
• Code is easy to follow
• PR size is sensible
• Commit history is sensible and tidy

Info on PRs

The checks above are guidelines. They don't all have to be ticked, but they should all have been considered.

[jamie-bbc]

I'm happy with this from what I've read - LGTM! Approving this, but happy if you want a second opinion.
Just a nit that each time put_urls is mentioned there shouldn't be an apostrophe.

[Akshay-Narayan-Pai]

Is put_url becoming put_urls ? Then are we having both in API then slowly deprecating ? Or here as per the changes it is seeming like get_urls is becoming get_url but I don't see a openapi spec key change either

[j616]

Is put_url becoming put_urls ? Then are we having both in API then slowly deprecating ? Or here as per the changes it is seeming like get_urls is becoming get_url but I don't see a openapi spec key change either

The approach I've taken in this PR is to keep the structure of both get_urls and put_url the same. I've added a presigned flag to the /storage POST method request body to allow clients to select pre-signed URLs, and to the response body to signal if a URL is presigned.

My intent is to keep this change backwards compatible as this is a core part of the API. I also feel like a list of URLs makes more sense on the read side than the write side. On the write side, the client either specifically knows which Storage Backend they wish to use, or they are happy to accept the default. If they have a preference for pre-signed/not then they will signal that by setting the presigned parameter. On the read side, a consuming Client often can't know up front which Storage Backend(s) Objects are available in. And in some cases, such as zero-copy-edit, may vary throughout the Flow. We do allow consuming Clients to filter the URLs returned where they have that knowledge, but we have to provide the ability to return a list so Clients can select based on what is available and information such as logical/geographical location. One could argue that its superfluous to return both presigned and non-presigned variants for the same Object Instance on the read side where a preference hasn't been stated, and perhaps we should call that out in the spec. But I think that's an implementation decision to some extent.

[Akshay-Narayan-Pai]

makes sense thanks for explanation, it was somewhat confusing with apostrophe