Asset versioning feature disabled results in a 403 error

By briefly running through the suggested changes, I foresee the potential of a code conflict. The self-explanatorily incorrect assumption of the inline comment

“// We can assume, that the latest version is the last item of the array.”

has been overridden once already in #3424689: Look for the "finalized" asset version not the latest modified.

Not counting this one, there are already 5–6 other open tickets already in Needs Review status. Most of them means a significant amount of code change. To avoid double-work I would suggest let's focus on getting them merged first, then get return here with a fresher 1.1.x branch.

Therefore I dare to mark this as Postponed for now but feel free to switch back if you feel it's urgent to work on.

Now MR tested, I confirm that it solves the 403 error.

I also agree with renaming our DAM client's getAssetVersionList() method to a more generic getAssetDetails() which will better describe its functioning.

Still I suggest to let's wait until #3424689: Look for the "finalized" asset version not the latest modified lands, then it will be easier to integrate these changes.

Note to ourselves: once starting to work on this issue just make sure that both occurrences of error message “Cannot get asset version list from API” in different classes are aligned with these changes.

Some thoughts on the Widen API v1/v2 usage

The Client\AcquiaDamClient::getAssetVersionList() in the current 1.0.x dev HEAD calls Widen API like this:

$response = $this->get("https://$domain/api/rest/asset/uuid/$id/assetversions"); (see API docs)

Which is provided by the v1 API. This MR suggests replacing this method with a different one, which would call v2 API:

$response = $this->get("/v2/assets/$id"); (see API docs)

Generally, I agree with that as it leans towards modernisation. However, now I checked our source code and at some point, we already rely on v2 API endpoints, for example AcquiadamAuthService::sendAuthRequest() (source).

This mixed usage of Widen API causes some heavy feelings for me. I think we could – after some discussion – put some work into searching through the entire codebase and checking all external HTTP calls (heads up, not only the Client class!) to ensure that the next stable release of this module will rely on exclusively on Widen API v2.

Tests are failing on D9, setting back to NW.

• MR updated to fresh 1.0.x target branch
• The Client class reworked to rely on API v2 for fetching asset versions (points of comment #8 are still valid)
• API response caching improved
• Test adapted to the code changes

Ready for review.