This content has been archived.

Different Service REST rules can be called for distinct resource URIs

Different Service REST rules can be specified for different resource URIs. This functionality provides different processing options, request handling, and response handling for each distinct resource URI. Additionally, it eliminates the need to maintain complex logic to handle all possible resource URI paths.

Resource URIs and URI templates

URI templates allow different Service REST rules to be defined for distinct resource URIs. You define these fields when you create a Service REST rule. The components that make up a resource URI include:

  • Service package – A data instance that supports the deployment of services. For more information about service packages, see About Service Package data instances.
  • Service version - The version number of a service rule.
  • URI template - A template that supports literal and variable path parameters. With this component, you can map a resource URI to a Service REST rule.
    Rules that were created before Pega® Platform 7.3.1 have resource paths instead of URI templates.

The following table illustrates distinct resource URIs that can be mapped to different Service REST rules:

Service package Service version URI template Resource URI
api v1 cases api/v1/cases
api v1 cases/{ID} api/v1/cases/C_100
api v1 cases/{ID}/attachments api/v1/cases/C_100/attachments
api v1 cases/{ID}/attachments/{attachmentID} api/v1/cases/C_100/attachments/A_100

Because each resource URI contains a distinct URI template, each resource URI can be mapped to a different Service REST rule.

URI template component requirements

There are several formatting requirements for the variable and literal components of a URI template. The following requirements apply to components of a URI template:

  • The first component in a URI template must be a literal component.
  • Variable components must start with an opening brace: { and end with a closing brace: }. These characters cannot be nested.
  • Variable components cannot be empty.
  • A component cannot contain both literal and variable syntax, for example, api_{id}.
  • Components cannot start with special characters, except for opening and closing braces { } and a slash mark: /.
  • Components cannot contain reserved characters such as a question mark: ? or a number sign: #.
  • Regular expression syntax, for example, {id :.+}, is not supported.

Service REST rule resolution

When you search for a Service REST rule, the system filters candidate rules based on a requestor's ruleset list, which defines the rulesets and versions that the requestor can access. Circumstance-qualified and time-qualified resolution features are not available for the Service HTTP rules. The class hierarchy is not relevant for Service REST rule resolution.

Rules that are created in Pega 7.3.1 take precedence over legacy rules in Service REST rule resolution. Additionally, rules with matching literal components in their URI templates take precedence over rules with variable components.

New rule precedence

If the following Service REST rules are in the system and a service is invoked with the following resource URL:

http://MyServer:8080/prweb/PRRestService/TestServicePkg/Sample/TestRestService/test/12345,

rule 2 runs instead of rule 1. In this case, the resource URL matches rule 1 and rule 2, but because rule 2 was created after rule 1, precedence is given to rule 2.

However, if the service is invoked with the following resource URL:

http://MyServer:8080/prweb/PRRestService/TestServicePkg/Sample/TestRestService/test

or:

http://MyServer:8080/prweb/PRRestService/TestServicePkg/Sample/TestRestService,

rule 1 runs instead of rule 2. In both of these cases, the resource URLs do not match the URI template of rule 2, so precedence is given to rule 1.

Rule1: Legacy rule created before version 7.3.1

Ruleset: TestOneRuleset:01-01-01

Customer package: TestServicePkg

Customer class: Sample

Resource path: /test/{resourceId}

Identifier: TestRestService

Rule 2: Rule created in or after version 7.3.1

Ruleset: TestOneRuleset:01-01-01

Service package: TestServicePkg

Sample version: Sample

URI template: TestRestService/test/{resourceId}

Identifier: TestRestService_test_var_1234

Literal component precedence

If the following rules are in the system and a service is invoked with the following resource URL:

http://MyServer:8080/prweb/PRRestService/TestServicePkg/Sample/TestRestService/id,

rule 2 runs instead of rule 1. In this case, the resource URL matches rule 1 and rule 2, but because the URI template in rule 2 contains a literal component and rule 1 contains a variable component, precedence is given to rule 2.

However, if the service is invoked with the following resource URL:

http://MyServer:8080/prweb/PRRestService/TestServicePkg/Sample/TestRestService/6789,

rule 1 runs instead of rule 2. In this case, the resource URL does not exactly match rule 1 or rule 2, but because the only component in the resource URL is a variable, precedence is given to the rule that also has a variable component.

Rule 1: Ruleset: TestOneRuleset:01-01-01

Customer package: TestServicePkg

Customer class: Sample

Resource path: TestRestService /{id}

Identifier: TestRestService_var_1234

Rule 2: Ruleset: TestTwoRuleset:01-01-01

Service package: TestServicePkg

Service version: Sample

URI template: TesttRestService/id

Identifier: TestRestService_id_3456


100% found this useful

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.