Choosing between a Pega API and a custom API

From PegaWiki
This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Choosing between a Pega API and a custom API

Description Factors to weigh in while choosing between Pega API and strongly typed custom API before building a new REST API
Version as of 8.5
Application Pega Platform
Capability/Industry Area Data Integration

Choosing between a Pega API and a custom API
This article has been moved over to our Pega Community here in order to align with our larger content strategy. Please update any bookmarks or links that you may have to this location.

Pega API

Pega Platform provides an extensive set of APIs that you can use to manage and interact with all aspects of your application, such as cases and assignments.

For more information, see Pega APIs and services.

Sample scenarios

Consider the following sample use cases for Pega APIs:

  • An external application needs to get a list of attachments of a case from a Pega Platform application.
  • An external application needs to get the case details from a Pega Platform application and make subsequent API calls to update the case details.

For more examples, see Pega API example use cases.

Strongly typed custom API

In Pega Platform, you can create custom REST/JSON services for external systems to integrate with your Pega Platform applications to request, receive, send data, or invoke an action. You can call any of the custom API services by using standard HTTP methods (for example, GET, POST, or PUT).

For more information about building custom APIs, see Building APIs.

Sample scenarios

Consider the following sample use cases for custom APIs:

  • If an external third-party application needs to access policy details from a Pega Platform application, your application must expose a REST service with the required parameters and provide a response with policy details.
  • If an external application needs to notify your application based on which you are going to process an event, your application must expose a custom REST service.

For more information, see Service REST rules.

When to choose a Pega API over a strongly typed custom API

The main difference between a Pega API and a custom API is your ability to clearly define the contract in resource-oriented APIs.

Consider the following characteristics of the Pega API:

  • If external applications need to access some of the generic resources from a Pega Platform application, they can immediately use multiple Pega API services as part of a single process or as part of multiple business application processes, without having to build a custom API.
  • Pega-provided API is generic in nature. Familiarize yourself with the Pega Platform application data model so that you can correctly format requests and understand responses from the Pega API.
  • Pega APIs communicate only in generic terms, such as cases, about the resources of your application. This approach works, but it requires callers to go into the product to understand how to use this API. The APIs do not tell you exactly what a request or response looks like, as each application has its own case types.
  • If you plan to build custom front-end experiences for Pega Platform applications without encoding business logic into each channel, you can use Pega Digital Experience (DX) APIs which, in turn, use Pega API services. For more details, see Pega Digital Experience (DX) API.

Custom APIs offer the following functionality:

  • If you want to provide an API that is more specific to your application, and that others can use without going into the application or knowing anything about the implementation, you need to define more strongly typed APIs.
  • Pega API does not provide any action-oriented APIs; all APIs are resource-oriented. If you need to create action-oriented APIs, for example, for an external caller to notify a Pega Platform application that a specific event has occurred without knowing how the API handles that event, you need to build custom APIs.
  • When you define your own APIs, you can define the requests and responses more specifically by using the actual data model of your application, which leads to a much clearer contract that requires no additional in-product research for callers.