Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-24468

Add the content/download url to the Binary Field Values in REST

    Details

      Description

      Add a downloadUrl to the value of BinaryFile / Media fields in REST payloads. It could re-use the uri or url properties, since the physical path stored here can't be used as-is (rewrite rules)

        Activity

        Hide
        Bertrand Dunogier added a comment -

        There are several impediments here.

        Persistence and HTTP cache clearing because of Field Def Identifier

        First, about the route chosen for content/download. It includes the field def identifier. Having it implies that the SPI cache and HTTP cache are cleared when the ContentType is updated (at least when this field def identifier is changed). It currently is not, and it is an issue in all cases described below.

        Adding the download url to the Field in REST

        Using the FieldType Processor

        One way was to use the REST Binary FieldTypeProcessor. It only receives the hash of the FieldValue properties. We don't have the data we'd need to generate the link (we need the content id and field def identifier).

        Using the BinaryBase External Storage

        The other one is to use the BinaryBase external storage handler, and add the downloadUrl property in the Field value directly. Semantically, it does make sense since the downloadable file is an externally stored data of the FieldType. The REST FieldType processor would then add the hostname, like it currently does with the var/site/storage path.

        An idea could be to add a new PathGenerator implementation. But we only have access to the VersionInfo and FieldValue: we still miss the Field def identifier. We could fix this by adding another PathGenerator implementation, in a higher layer, that uses the public API to find out the FieldIdentifier.

        But the whole idea would add ContentType related data to the persistence cache, taking us back to the original issue.

        Show
        Bertrand Dunogier added a comment - There are several impediments here. Persistence and HTTP cache clearing because of Field Def Identifier First, about the route chosen for content/download . It includes the field def identifier. Having it implies that the SPI cache and HTTP cache are cleared when the ContentType is updated (at least when this field def identifier is changed). It currently is not, and it is an issue in all cases described below. Adding the download url to the Field in REST Using the FieldType Processor One way was to use the REST Binary FieldTypeProcessor . It only receives the hash of the FieldValue properties. We don't have the data we'd need to generate the link (we need the content id and field def identifier). Using the BinaryBase External Storage The other one is to use the BinaryBase external storage handler , and add the downloadUrl property in the Field value directly. Semantically, it does make sense since the downloadable file is an externally stored data of the FieldType. The REST FieldType processor would then add the hostname, like it currently does with the var/site/storage path. An idea could be to add a new PathGenerator implementation . But we only have access to the VersionInfo and FieldValue: we still miss the Field def identifier. We could fix this by adding another PathGenerator implementation, in a higher layer, that uses the public API to find out the FieldIdentifier. But the whole idea would add ContentType related data to the persistence cache, taking us back to the original issue.
        Hide
        Bertrand Dunogier added a comment -

        After discussion with André Rømcke, we concluded that we would change the route used for content/download to use the field ID instead of the field definition identifier.

        That way, it will be easy to generate the download url from the BinaryBase external storage, without any content type data leaking into cache.

        Show
        Bertrand Dunogier added a comment - After discussion with André Rømcke , we concluded that we would change the route used for content/download to use the field ID instead of the field definition identifier. That way, it will be easy to generate the download url from the BinaryBase external storage, without any content type data leaking into cache.
        Hide
        Bertrand Dunogier added a comment - - edited

        Merged to master@f462ae1.

        Documentation required

        Public API: Binary FieldTypes Value url property change

        The `url` property of

        {BinaryFile\Value}

        and

        {Media\Value}

        now contain the absolute URL to the file, with the format

        /content/download/{contentId}/{fieldId}

        .

        REST API: The `url` property contains a valid download URL

        The `url` property of Binary Fields in REST contain a valid URL, of the same format than the Public API, prefixed with the same host than the REST Request.

        New download route

        The download route documented above will redirect to the right siteaccess based on the fieldId's language (the legacy storage engine uses one fieldId per language).

        Testing

        Limited to the BinaryFile and Media fieldtypes.
        We must check that the url property in Field Value for these fieldtype is a valid /content/download URI, both in Public API and REST. In REST, the URL must redirect to the language of the attribute (e.g. fre-FR attribute => fre-FR siteaccess, etc).

        Show
        Bertrand Dunogier added a comment - - edited Merged to master@f462ae1 . Documentation required Public API: Binary FieldTypes Value url property change The `url` property of {BinaryFile\Value} and {Media\Value} now contain the absolute URL to the file, with the format /content/download/{contentId}/{fieldId} . REST API: The `url` property contains a valid download URL The `url` property of Binary Fields in REST contain a valid URL, of the same format than the Public API, prefixed with the same host than the REST Request. New download route The download route documented above will redirect to the right siteaccess based on the fieldId's language (the legacy storage engine uses one fieldId per language). Testing Limited to the BinaryFile and Media fieldtypes. We must check that the url property in Field Value for these fieldtype is a valid /content/download URI, both in Public API and REST. In REST, the URL must redirect to the language of the attribute (e.g. fre-FR attribute => fre-FR siteaccess, etc).
        Hide
        Miguel das Neves Jacinto (Inactive) added a comment -

        QA Approved

        Show
        Miguel das Neves Jacinto (Inactive) added a comment - QA Approved

          People

          • Assignee:
            Unassigned
            Reporter:
            Bertrand Dunogier
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 1 hour, 15 minutes
              1h 15m

                Agile