feat: use media route

[kptdobe]

Use the new /media route - see adobe/da-admin#178

Note: only merge this one when adobe/da-admin#178 has been deployed to production.

Test: https://media--da-live--adobe.aem.live/?da-admin=stage

UX in case of error (like if image is > 20MB) needs to be reviewed.

[aem-code-sync]

Hello, I'm the AEM Code Sync Bot and I will run some actions to deploy your branch and validate page speed.
In case there are problems, just click a checkbox below to rerun the respective action.

• Re-run PSI checks
• Re-sync branch

Commits

• 8a147d5 ✅ (latest)
• adaa0e7 ✅
• 1ba38ca ✅

[aem-code-sync]

	Page	Scores	Audits	Google
📱	/?da-admin=stage
🖥️	/?da-admin=stage

[auniverseaway]

I really like this, but its probably something we should do during the Helix6 / DA2 cycle... I get the problem at hand, so if we cannot come up with a solution with fewer tradeoffs, we should carry this out.

I know why it needs to exist, but creating a media route seems needlessly tedious to the API consumer. A developer should be able to upload to source and we figure it out where it needs to go. We know what the mime type is so we know if it should go to Media Bus. I don't want us in the same mess as Content Bus / Media Bus where something can live in either place (ala SVG). There should be one code path to get a source file into DA and we decide where it needs to live in the repository.

This obviously works where we do not care where these files live, but it also creates a fork in implementations where if I upload a file direct (drag and drop in browse), its a different code path... these are back to living in DA. I would like us to use Media Bus e2e if we're going to use Media Bus as our asset store.

Potential paths forward

1. Update the source API
   1. Source API detects the extension / mime type and correctly routes the image to Media Bus.
   2. We need to be able to have a ref for direct uploads... if I upload to /org/site/random/my-image.jpg it needs to map back to a Media Bus hash. Yes, a bigger lift.
   3. We determine what we put in the doc that is relatively consistent with the other use case. The dot convention seemed fine, but I also wouldn't be opposed to something else that's more transparent / stable... /media/... even.
2. Re-route doc drops
   1. Instead of dropping into a dot folder, we place these somewhere like /media/path-of-current/page/my-image.jpg. Page moves would not break any more. Problem is solved.
   2. We push this problem to be solved with Helix6 / DA2.
3. Any other ideas?

[kptdobe]

We can definitively think the "API routes" differently.
I have created the /media API end point just because it is an upload service and not a proper REST API.
We could definitively use /source with a minimum of intelligence. If you upload an asset to /org/site/a/b/c/my-image.jpg, you get: /org/site/media_id.jpg as a response uri. That's the most stable path we can use.

Side note: /org/site/a/media_id.jpg, /org/site/a/b/media_id.jpg, /org/site/a/b/c/media_id.jpg or /org/site/x/y/z/media_id.jpg would work too. Which is an implementation detail but helps to use relative paths and avoid all complicated asset references. /stable or /media would work too but is this really necessary ? (especially all assets would be like /media/media_...)