Details

    • Type: Epic Epic
    • Status: Specification
    • Priority: High High
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Platform > REST API v2
    • Labels:
    • Epic Name:
      REST include

      Description

      Goal: Reduce need for several round trips to REST server

      Abstract:
      1. Let caller of REST api specify that links in a document should be included in the document itself to avoid server round trips.
      Do this by inlining includes on the server for best DEV setup performance, and with cache tags for production cache invalidation covered
      2. Take advantage of this in UI

      Do this in similar way as specified in JSON API for familiarity, however with media type structure we have today.

      m2

      See REST improvment epic for stories needed to better take advantage of thus form UI and headless use cases.

      m3

      Possible future m3 could be to look into getting more cache efficiently by instead of inlining the includes, use one of:

      • ESI (cache efficiency, but depends on feature to set media type or url, like .json, as it won't work with xml because of xml structure)
      • HTTP/2 Server Push (cache efficient, however not supported by Varnish yet, and client would need to support it)

        Issue Links

          Issues in Epic

            Activity

            Hide
            Damien Pobel added a comment - - edited

            In EZP-26047, I tried to identify where we are queuing/chaining REST requests in PlatformUI, so below, you can find the main places where this is happening. That does not mean we have to fix all the cases below or do the same operations in one request because:

            1. in some cases, it will probably be tricky because the request chaining requires some business logic which might be hard to express in an HTTP request
            2. in a lots of cases, we need the Content Type(s) associated with some Content items but that case should probably be fixed in a different way (still I mentioned it there for the record)

            My Drafts dashboard block

            The requests chain is the following:

            • /api/ezp/v2/user/users/14/drafts to get the VersionItem list
              • for each version, we load the corresponding ContentInfo /api/ezp/v2/content/objects/<ContentId> (this link is found in VersionList.VersionItem.<n>.VersionInfo.Content)
                • load (1 or several times now?) ContentType /api/ezp/v2/content/types/<ContentTypeId> found in the list afterwards for displaying icons and type name

            Display a Content item (+ detail tab)

            • /api/ezp/v2/content/locations/<LocationId>
              • /api/ezp/v2/content/objects/<ContentId>?languages=<displayLanguageCode> to get the Content item in the correct language (languages parameter is manually added but known in advance)
                • /api/ezp/v2/user/users/<LastModifierId> (this link is found in Content.CurrentVersion.Version.VersionInfo.Creator)
              • /api/ezp/v2/content/types/<ContentTypeId> (given by the ContentInfo in the Location)
            • /api/ezp/v2/user/users/<OwnerId> (given by the ContentInfo, Location.ContentInfo.Content.Owner

            Version tab

            • /api/ezp/v2/content/objects/<ContentId>/versions
              • for each VersionInfo /api/ezp/v2/user/users/<CreatorId> (found in VersionList.VersionItem.<n>.VersionInfo.Creator)

            Subitem "list"

            • /api/ezp/v2/views (to search for Locations)
              • load each unique ContentType /api/ezp/v2/content/types/<ContentTypeId> found in the list afterwards for displaying icons and type name
              • /api/ezp/v2/views to get the corresponding full Content item

            Subitem "grid"

            • /api/ezp/v2/views (to search for Locations)
              • load each unique ContentType /api/ezp/v2/content/types/<ContentTypeId> found in the list afterwards for displaying icons and type name
              • /api/ezp/v2/views to get the corresponding Content item
                • for each Content with an image /api/ezp/v2/content/binary/images/<ContentId>-<FieldId>/variations/<the configured variation>

            This is an example where the requests flow is the result of quite some business logic. (Off topic idea: maybe we could implement a content.image or contentInfo.image like we have a content.name / contentInfo.name to get a representation of a Content item as an image ?)

            Resolving embed images

            • /api/ezp/v2/views (to search for embedded Content items)
              • for each Content /api/ezp/v2/content/binary/images/<ContentId>-<FieldId>/variations/<the configured variation>

            (Like the previous case)

            Tree in the UDW when it's configured to bring the Content item

            for each tree level to display:

            • /api/ezp/v2/views to search for Locations at a given level
              • load each unique ContentType /api/ezp/v2/content/types/<ContentTypeId> found in the list afterwards for displaying icons and type name
              • /api/ezp/v2/views to load the corresponding Content items

            Content Type Selector

            • /api/ezp/v2/content/typegroups to list the Content Type Groups
              • for each Content Type Group /api/ezp/v2/content/typegroups/<ContentTypeGroupId> (link found in ContentTypeGroupList.ContentTypeGroup.<n>._href)
                • for each Content Type Group /api/ezp/v2/content/typegroups/<ContentTypeGroupId>/types (link found in ContentTypeGroup.ContentTypes)
            Show
            Damien Pobel added a comment - - edited In EZP-26047 , I tried to identify where we are queuing/chaining REST requests in PlatformUI, so below, you can find the main places where this is happening. That does not mean we have to fix all the cases below or do the same operations in one request because: in some cases, it will probably be tricky because the request chaining requires some business logic which might be hard to express in an HTTP request in a lots of cases, we need the Content Type(s) associated with some Content items but that case should probably be fixed in a different way (still I mentioned it there for the record) My Drafts dashboard block The requests chain is the following: /api/ezp/v2/user/users/14/drafts to get the VersionItem list for each version, we load the corresponding ContentInfo /api/ezp/v2/content/objects/<ContentId> (this link is found in VersionList.VersionItem.<n>.VersionInfo.Content ) load (1 or several times now?) ContentType /api/ezp/v2/content/types/<ContentTypeId> found in the list afterwards for displaying icons and type name Display a Content item (+ detail tab) /api/ezp/v2/content/locations/<LocationId> /api/ezp/v2/content/objects/<ContentId>?languages=<displayLanguageCode> to get the Content item in the correct language (languages parameter is manually added but known in advance) /api/ezp/v2/user/users/<LastModifierId> (this link is found in Content.CurrentVersion.Version.VersionInfo.Creator ) /api/ezp/v2/content/types/<ContentTypeId> (given by the ContentInfo in the Location) /api/ezp/v2/user/users/<OwnerId> (given by the ContentInfo, Location.ContentInfo.Content.Owner Version tab /api/ezp/v2/content/objects/<ContentId>/versions for each VersionInfo /api/ezp/v2/user/users/<CreatorId> (found in VersionList.VersionItem.<n>.VersionInfo.Creator ) Subitem "list" /api/ezp/v2/views (to search for Locations) load each unique ContentType /api/ezp/v2/content/types/<ContentTypeId> found in the list afterwards for displaying icons and type name /api/ezp/v2/views to get the corresponding full Content item Subitem "grid" /api/ezp/v2/views (to search for Locations) load each unique ContentType /api/ezp/v2/content/types/<ContentTypeId> found in the list afterwards for displaying icons and type name /api/ezp/v2/views to get the corresponding Content item for each Content with an image /api/ezp/v2/content/binary/images/<ContentId>-<FieldId>/variations/<the configured variation> This is an example where the requests flow is the result of quite some business logic. (Off topic idea: maybe we could implement a content.image or contentInfo.image like we have a content.name / contentInfo.name to get a representation of a Content item as an image ?) Resolving embed images /api/ezp/v2/views (to search for embedded Content items) for each Content /api/ezp/v2/content/binary/images/<ContentId>-<FieldId>/variations/<the configured variation> (Like the previous case) Tree in the UDW when it's configured to bring the Content item for each tree level to display: /api/ezp/v2/views to search for Locations at a given level load each unique ContentType /api/ezp/v2/content/types/<ContentTypeId> found in the list afterwards for displaying icons and type name /api/ezp/v2/views to load the corresponding Content items Content Type Selector /api/ezp/v2/content/typegroups to list the Content Type Groups for each Content Type Group /api/ezp/v2/content/typegroups/<ContentTypeGroupId> (link found in ContentTypeGroupList.ContentTypeGroup.<n>._href ) for each Content Type Group /api/ezp/v2/content/typegroups/<ContentTypeGroupId>/types (link found in ContentTypeGroup.ContentTypes )
            Hide
            Roland Benedetti added a comment -

            Hi, I'm doing some clean up on the board. We sometime call this REST Embedding, and some others (like here) REST Include.
            André RømckeBertrand Dunogier Am I correct that we are talking about the same thing?

            then should we decide of a single name?
            I vote for REST Embedding.

            Show
            Roland Benedetti added a comment - Hi, I'm doing some clean up on the board. We sometime call this REST Embedding, and some others (like here) REST Include. André Rømcke Bertrand Dunogier Am I correct that we are talking about the same thing? then should we decide of a single name? I vote for REST Embedding.
            Hide
            André Rømcke added a comment - - edited

            Roland Benedetti We changed the name to include some time ago, so voting has closed Reason was to align name and concept with JSON API* to not introduce a new concept to the world, and avoid confusion with "Embeds" in RichText.

            So once we get back at this soon the PR and such will be updated to reflect this.

            * http://jsonapi.org/format/#fetching-includes

            Show
            André Rømcke added a comment - - edited Roland Benedetti We changed the name to include some time ago, so voting has closed Reason was to align name and concept with JSON API* to not introduce a new concept to the world, and avoid confusion with "Embeds" in RichText. So once we get back at this soon the PR and such will be updated to reflect this. * http://jsonapi.org/format/#fetching-includes
            Hide
            Roland Benedetti added a comment -

            Ok, I missed the deadline
            I see the reasons.
            But then I'll rename everywhere it's also used (like roadmap documents...) or it gets very confusing

            Show
            Roland Benedetti added a comment - Ok, I missed the deadline I see the reasons. But then I'll rename everywhere it's also used (like roadmap documents...) or it gets very confusing

              People

              • Assignee:
                Bertrand Dunogier
                Reporter:
                André Rømcke
              • Votes:
                0 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated: