[Spike] Investigate Contentlet API Endpoints for Listing/Filtering/Pagination Capabilities for the Relationship field

[oidacra]

Parent Issue

• [EPIC] Implement Advanced Relationship Field  #30495

User Story

As a developer, I want to investigate existing API endpoints for contentlet management, so I can implement a dialog component with listing, filtering, and pagination capabilities for displaying content information (title, step, description, last updated).

Dialog

Search configuration:

Acceptance Criteria

• Research and document existing endpoints for contentlet listing
• Verify if the following functionalities are supported:
  • Filter by contentType (When the dialog is called, we will make a request by a defined ContentType)
  • Pagination capabilities (page?/offset?/limit/perPage)
  • Filtering by fields (title, description)
  • Search values config: languageId and Site/Folder
  • Sorting options (column and direction)
• Document response structure and available fields
• Create sample requests demonstrating or suggested POST:
  • Basic listing with pagination
  • Filtering scenarios
  • Sorting examples

Proposed Objective

Technical User Experience

Proposed Priority

Priority 2 - Important

External Links

N/A

Assumptions & Initiation Needs

Quality Assurance Notes & Workarounds

The findings from this spike will be used to implement a dialog component showing:

• Title
• Description
• Sorting capabilities
• Filtering options
• Pagination controls

[jcastro-dotcms]

Spike Findings

The current search dialog displayed when looking for Contentlets in a Relationship field uses the very same logic that the Content Search portlet uses. This means that there's a massive amount or generic code in it, and there's currently no direct replacement in the any of the Content REST Endpoints we have.

In terms of the Java classes:

• The ContentletAjax is the one in charge of returning the results, with any additional filtering and pagination.
• The StructureAjax returns what fields Users can use to filter contents.

Even though a lot of that information can be retrieved via the /api/content or /api/content/_search methods, specific metadata such as displaying the total amount of records might need some additional logic. This is not considering any additional logic that may be added to the backend in order to abstract unnecessary Lucene code from the front-end layer.

Here's an example of what a filtered content search looks like with the /api/content endpoint:

curl --location 'http://localhost:8080/api/content/language/1/limit/5/offset/0/live/true/orderby/webPageContent.title asc/query/+contentType:webPageContent +(webPageContent.title:*event*  webPageContent.title_dotraw:*event*) +variant:default' \
--header 'Authorization: Basic YWRtaW5AZG90Y21zLmNvbTphZG1pbg=='

And this is what it may look like with the /api/content/_search endpoint:

curl --location 'http://localhost:8080/api/content/_search' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic YWRtaW5AZG90Y21zLmNvbTphZG1pbg==' \
--data '{
    "query": "+contentType:webPageContent +working:true +deleted:false +languageId:1 +catchall:cont*",
    "sort": "score,modDate desc",
    "limit": 2,
    "offset": 0
}'