Add `rev` Parameter for image URLs for RELEASE APIs

[alexander-nikiforov-intentive]

Hi,

We are using CaaS Images behind the proxy to get Caching for images for 1 Year.

We have implemented this functionality because we saw at Preview that the FSXA-API adds rev Parameter,
that invalidates the Cache every time the image is updated.

Here is the example preview URL:

• https://pepperlfuchsprod-media.e-spirit.cloud/0393862a-0579-4fc6-860e-db3cc253dc1e/preview/mam_upload/EC_JH_20240522_01_polyplan_logo_200px.webp?rev=854712

We have unfortunately noticed too late that Revision parameter for images in buildMediaUrl() (https://github.com/e-Spirit/javascript-content-api-library/blob/master/src/modules/CaaSMapper.ts#L226) is not added when using LIVE CaaS APIs

This way our Website Caching cannot be used.

Could you update the buildMediaUrl function so that one can add rev Parameter at LIVE APIs as well.

Something like this?

buildMediaUrl(url: string, rev?: number, fsxaConfig: Object) {
    if (rev && fsxaConfig.useRevisionParameterAtRelease === true) {
      url += `${url.includes('?') ? '&' : '?'}rev=${rev}`
    } else if (rev && this.api.contentMode === FSXAContentMode.PREVIEW) {
      url += `${url.includes('?') ? '&' : '?'}rev=${rev}`
    }
    return url
  }

It is very important feature for us, that currently does not allow us to use effective Caching when image is updated.

Reference to Support Ticket https://support.crownpeak.com/hc/en-us/requests/163337

[nico-mcalley]

Hi alexander-nikiforov-intentive

Thank you for sharing your request.
There are two ways you could move forward:

1. Submit a Pull Request (PR): We work together to bring your improvements to this repository.
2. Create a Fork: Alternatively, you can implement the feature independently in a forked version of the project.

A fork can be a good option, especially if you prefer to move quickly or tailor the implementation to your specific needs. While it may lead to minor differences from the upstream project, it allows for greater flexibility.
A Pull Request may be slower and more work, as it requires review, adherence to project standards, and may be rejected if it doesn't align.
The use case you describe appears to be relevant and potentially beneficial for other users of this project as well.
If you prefer to submit a PR, please make sure it meets the following criteria:

• The changes are concise and limited in scope (eg affecting the least amount of files necessary)
• Backward compatibility is maintained
• New functionality is thoroughly tested
• Existing tests continue to pass without issues
• The PR can be merged cleanly without conflicts

Also, please ensure you read and follow our contribution guide when preparing your PR.

Best regards,
Nico