Configuring endpoint access for generated endpoints

Endpoint access defines the aspects of an endpoint's behaviors that are available to a caller. This includes:

What endpoints are available to the caller?
What operations can a caller call on an available endpoint?
What fields can the caller specify in a request payload or get in a response payload?

For more information on the general behavior of endpoint access, see Endpoint access.

When running the REST Endpoint Generator, several prompts pertain to endpoint access. This includes:

Which roles can access the GET collection and GET element endpoint?
Which roles can access the POST collection endpoint?
Which roles can access the PATCH element endpoint?
Which roles can access the DELETE element endpoint?

Based on the responses, the REST endpoint generator adds code to the corresponding role.yaml files. Places where additional coding may be needed are flagged with the following comment:

TODO RestEndpointGenerator

You can search for these "TODO RestEndpointGenerator" comments in Studio to complete the configuration.

Code generated in role.yaml files

Providing access to all operations

If you specify that a given role has GET, POST, PATCH, and DELETE access to a generated endpoint, the REST endpoint generator adds the following code to the associated role.yaml file:

- endpoint: /<path>/<customEndpointCollection>
  # TODO RestEndpointGenerator : Adjust the permissions appropriately
  methods:
  - GET
  - POST
- endpoint: "<path>/<customEndpointCollection>/*"
  # TODO RestEndpointGenerator : Adjust the permissions appropriately
  methods:
  - GET
  - DELETE
  - PATCH

The first block grants the ability to retrieve a collection and the ability to create a resource.

The second block grants the ability to retrieve an element, to modify an element, and to delete an element. (A single * wildcard indicates access is provided for anything one level below the current endpoint level.)

For example, suppose you generated endpoints for the CustomEntity_Ext data model entity and added GET, POST, PATCH, and DELETE access to these endpoints to the Manager role. The REST endpoint generator would add the following lines to the Manager.role.yaml file:

- endpoint: /account/v1/accounts/custom-entities-ext
  # TODO RestEndpointGenerator : Adjust the permissions appropriately
  methods:
  - GET
  - POST
- endpoint: "/account/v1/accounts/custom-entities-ext/*"
  # TODO RestEndpointGenerator : Adjust the permissions appropriately
  methods:
  - GET
  - DELETE
  - PATCH

The first block grants the ability to retrieve a collection of CustomEntities_Ext and the ability to create a CustomEntity_Ext.

The second block grants the ability to retrieve a specific CustomEntity_Ext, to modify a CustomEntity_Ext, and to delete a CustomEntity_Ext.

Limiting access to only some operations

During the REST endpoint generator prompts:

If you specified GET access for a given role, but not POST access, the POST operation is omitted from the first block.

If you specified GET access for a given role, but not PATCH (or DELETE) access, the PATCH (or DELETE) operation is omitted from the second block.

If you did not specify GET access for a given role, then both blocks are omitted. (In order to POST, PATCH, or DELETE, the role must also have the ability to GET.)

Configuring code in role.yaml files

If you specified roles in response to the REST endpoint generator prompts, then the endpoint access code generated by the REST endpoint generator is likely to be usable as is. However, there may be cases where additional configuration is required. For example:

Guidewire recommends removing the TODO RestEndpointGenerator comments.
An insurer may want to add additional field-level access in the accessibleFields section.

For more information on how to configure role.yaml files, see Endpoint access.