DX API request and response elements

You can build a user interface that combines the resources of Pega Platform with an environment that is well-known to users by implementing Pega digital experience (DX) REST API. To fully take advantage of Pega DX API endpoints, understand their request and response elements.
For example, by using DX API endpoints in your external application, you can create a screen for creating loan requests that displays case details and fields to collect data. Then, a case worker can work on the request in a Pega application.

The main user interface elements that you can integrate into external software by using DX API are pages and views. When you build a custom user interface with DX API, you can use the Live UI tool as you create and process cases in a Pega test environment. Live UI shows you the page and view identifiers that you need as parameters for API calls.

Pages in DX API responses

In the API response body, the page element represents the screen that you build with a harness rule. The value in the name parameter is the identifier of harness. The following API endpoints return harness data:
GET /casetypes/{case type ID}
Returns the New harness in the creation_page element.
PUT /casetypes/{case type ID}/refresh
Refreshes and then returns the creation_page element, or the New harness. Then, the API refreshes and returns the body of the request in the response.
GET /cases/{case ID}/pages/{page ID}
Returns the indicated harness from the indicated case. For example, for a Confirm type harness, the value of the page ID paramater is Confirm.

Views in DX API responses

The view element in the response body represents the part of a screen that you build with a section rule. The value in the view ID parameter is the identifier of the view (section). A view can represent an action form for the end user to complete, such as a questionnaire that a user fills in. Other types of views might be informational, for example, an audit trail, or functional, for example, a place to enter notes about the case. A view can contain other views, just as a section can contain embedded sections. The following API endpoints return section data:
GET /assignments/{assignment ID}/actions/{action ID}
Returns the section for a specified assignment in the view element.
PUT /assignments/{assignment ID}/actions/{action ID}/refresh
Returns the section for a specified assignment in the view element. Then the API refreshes and returns the body of the request in the response.
GET /cases/{case ID}/actions/{action ID}
Returns the section for a specified case in the view element.
PUT /cases/{case ID}/actions/{action ID}/refresh
Returns the section for a specified case in the view element. Then the API refreshes and returns the body of the request in the response.
GET /cases/{case ID}/views/{view ID}
Returns a section for a case.
For example, in your application, you can use a top-level section in a screen where users create bugs. The following examples illustrates the structure:
Where:
viewID
is the ID of the section record in Pega Platform.
name
is the name of the section as it appears in Pega Platform.
appliesTo
is the name of the class that contains the section.

Additionally, API endpoints that include action parameters build the response from flow action rules.

The following sample shows the structure of the top-level block that is returned from the GET /assignments/{assignment ID}/actions/Create endpoint call:
Where:
caseID
is the ID of the case related to the assignment.
name
is the name of the flow action as it appears in Pega Platform.
actionID
is the ID of the flow action record in Pega Platform.