Proposal: Shortened URL Redirection for Adoptium Downloads #3769
Comments
|
Creating a new schema around " FWIW I've not seen a pushback to the length of the current URLs. |
|
I would be slightly concerned that we might end up discouraging the use of the API, or giving mixed messages, by making these URLs available. We have historically actively steered end users towards the API for such things and avoid advocating going directly to the endpoints, and while the API can feel certainly feel a bit more complex than it perhaps should (I often point people to https://adoptium.net/en-GB/blog/2023/08/early-access-builds/ for some simple JDK download examples - the ones that were on the front of the API site are no longer there) that is the path we have chosen for such automation up to now. In terms of Tim's comment about length I guess we're comparing:
On the telemetry point, can we not get that from the current API? And similarly from a flexibility perspective, we would cover that from the API too if we moved to an alternate hosting platform so I'm not yet convinced that this is compelling from that perspective. |
I hope we can withdraw the If we do need/wish to shorten the URL, how about we give Temurin JDK defaults to the
becomes
(I believe there is still value in maintaining the API version element) |
I think the big difference is that this would rely on someone to check the API for updates as opposed to being able to dynamically switch the backend and keep URLs valid. Here's an example (all hypothetical ofcourse) We decide to move from GitHub Releases to Artifactory for our binary releases: As things stand we could update the API to return the new links so the website would continue to work and many users who correctly use the API would receive the updated link and hopefully be able to download it with little to no changes in their code. But.... many users might have used templating logic to generate the download URLs or they might have gone to the website, clicked the latest version and then copied the source URL into their build CI - for all these users they are now broken. I'm not suggesting a replacement of the API here (I think that would be very counterproductive, rather I'm thinking of ways that we can further reduce the risk. |
So if I understand correctly, your proposal is that we continue to promote the current API, but serve up the
instead of currently returning a it would return a Is that correct? I'm asking because the original post refers to making user friendly download URLs for sharing, and I'm not sure that is the purpose of those redirected locations. IMHO we would end up with effectively two api routes for users. |
That's exactly the idea, perhaps the wording isn't very clear, it's simply to remove our dependency on |
|
This was discussed at the PMC meeting on Oct 9th as minuted. |
Summary
I propose implementing a new, shorter URL format for Adoptium download links using the domain
dl.adoptium.net. This approach simplifies the download URLs and allows us to dynamically redirect them to the corresponding binaries on GitHub releases.New URL Format
The new URL format would be
https://dl.adoptium.net/{major_version}/{openjdk_version}/{file_name}For example:
redirects to:
Implementation
I propose using Cloudflare Redirect Rules to handle the dynamic redirection. These rules allow us to capture different versions and file extensions, automatically redirecting users to the appropriate GitHub release page. Once implemented we would need to update the API to return download URLs using this URL shortner rather than the original github.com release link. Changing the API alone should capture nearly all use-cases.
Benefits
dl.adoptium.netdomain is shorter and easier to share, improving user experience.I have left a rule running in Cloudflare so I encourage people to try out the new URL and provide feedback!
The text was updated successfully, but these errors were encountered: