While JAX-RS remains a viable option for specific business needs, REST Builder is often a better fit for Liferay development.Consuming APIs and Presenting Data

• Fetching structured content like articles, product information, and user profiles
• Managing dynamic data for interactive components
• Ensuring real-time updates for collaborative tools

Effectively handling these data requirements is crucial for building responsive, personalized, and engaging user experiences.

Liferay DXP provides a comprehensive suite of features to address these frontend data requirements, catering to both traditional and modern development approaches. The headless framework enables developers to consume rich REST and GraphQL API endpoints from various Liferay modules such as Web Content, Documents and Media, Users, and custom Objects. Because these services are exposed through headless APIs, they become accessible to custom elements developed with client extensions. With this decoupled paradigm, you can develop lightweight components and applications that still leverage the full functionality of Liferay’s backend.

However, consuming APIs is only one half of the equation. Once you have the data available, you need a way to visualize it with a standardized layout and style that fits the rest of your application. Liferay frontend data sets provide a user interface tool to aggregate and present data from headless APIs, along with specialized client extensions for developers to fine-tune them.

Understanding Frontend API Calls

Delivering rich digital experiences means consuming API data securely, filtering it precisely, and ensuring it's served efficiently. Here, you’ll explore practical methods for consuming headless APIs within various frontend contexts.

Understanding API Call Approaches

Whether you're rendering Liferay fragments, displaying frontend client extensions, or building external applications, Liferay's headless APIs provide the data needed for flexible, dynamic user interfaces. These frontend API calls generally follow one of two patterns based on their origin:

• Client-to-Server: Made directly from the user's browser (e.g., via JavaScript). This is typical for client extensions and direct calls from fragments.
• Server-to-Server: Made from a server environment (e.g., using restClient in a Liferay fragment).

Client-to-server calls are common for browser-based logic (such as client extensions and dynamic dashboards with fragments), while server-to-server calls often happen during server-side rendering (e.g., static dashboards with fragments) or via intermediary backends.

Consuming APIs from Liferay Pages

Liferay pages assemble fragments, widgets, and frontend client extensions to build versatile user experiences. To create dynamic pages, these components often call Liferay APIs to retrieve data or execute operations.

To secure these API calls, Liferay provides a javascript utility Liferay.Util.fetch(). This utility wraps the regular javascript fetch() method and takes care of passing the required security tokens to the API based on the current session. Because it is the standard adopted by Liferay's built-in applications, this is the best practice when developing custom JavaScript client extensions within the platform.

Fragments support both client-to-server and server-to-server API calls. By leveraging access to the user’s session context, authentication for these API calls is simplified compared to fully external applications.

Frontend client extensions, particularly custom elements, function as micro-frontends running independently in the user’s browser. Like fragments, they use session data to authenticate API calls. However, because they exist outside Liferay’s server environment, frontend client extensions must use client-to-server API calls that rely on JavaScript or frameworks like React, Vue.js, or Angular.

Consuming APIs from External Applications

Many applications interact with Liferay’s APIs from entirely separate environments, creating a multi-channel experience. These headless frontends, which operate and render outside of Liferay, can include a wide variety of contexts.

While capabilities differ between external platforms, each requires efficient API interactions and explicit OAuth 2.0 authentication to integrate with Liferay. Once secured, these platforms can consume headless APIs to retrieve and manipulate data. This approach enables highly integrated and scalable applications that extend Liferay’s capabilities beyond its native UI.

Presenting Data with Frontend Data Sets

Frontend data sets act as virtual containers for aggregating data from sources using Liferay’s headless APIs. This data includes custom objects, documents, web content, and more. Once you’ve selected a data source, you can configure which fields to include and how to render them.

Liferay provides three visualization modes out of the box: table, card, and list. Each of these views has built-in support for sorting, filtering, pagination, and search to enrich the user experience by surfacing the right data as efficiently as possible.

• Table View is ideal for displaying structured data with multiple information-dense fields, such as support tickets.
• Card View is ideal for use cases that require scanning key details and summaries quickly, such as product catalogs.
• List View is ideal for presenting sequential data in a simple, legible format, such as system logs.

Because the presentation layer is decoupled from the data sources themselves, designers and content creators can style and interact with data without needing developer expertise to work with APIs.

Frontend Data Set Client Extensions

While the standard display modes offer a variety of configurations out of the box, some use cases require additional customization due to the complexity or specificity of the data involved. For these cases, developers can implement frontend data set (FDS) client extensions:

• The FDS cell renderer client extension packages JavaScript functions to render individual cells, or fields, in a data set. With this client extension, you can implement interactive elements within your frontend data set, such as buttons, links, and event handlers.
• The FDS filter client extension facilitates more complex filtering logic than you can achieve out of the box. You can code filters to handle different data sources and values dynamically, making your frontend data sets more responsive and context-sensitive.

Modern web applications often need to present the same data in different contexts, or present data from different sources in a cohesive display. You can do both with frontend data sets, which are reusable, modular, and customizable.

Conclusion

Retrieving and visualizing data is a critical function of any frontend solution. Liferay's headless APIs empower frontend developers to build secure, lightweight applications that can read, update, and manage the full spectrum of Liferay-managed data. Frontend data sets leverage the headless framework to provide a flexible no-code solution for retrieving, managing, visualizing, and interacting with structured data. In addition to this capability, frontend data sets offer deeper configuration options to developers through the cell renderer and filter client extensions.

Next, you’ll explore strategies for developing and optimizing frontend applications in Liferay.