Request inclusion

Request inclusion is a technique for POSTs and PATCHes in which the call consists of the following:

  • A single parent request that creates or modifies a resource
  • One or more child requests that create or modify resources related to the parent resource

If either the parent request or any child request fails, the entire request fails.

The parent resource is often referred to as the root resource. The root resource is specified in the payload's data section. The related resources are specified in the payload's included section.

For example, a caller can use a single POST /accounts to create a new account, a set of AccountContacts for that account, a set of AccountLocations for that account, and a set of documents for that account.

In order to use request inclusion, the following must be true:

  • There must be a POST or PATCH endpoint for the root resource.
  • This endpoint must have the child resource as part of its included section.
  • There must also be a POST or PATCH endpoint for the child resource.

The syntax for request inclusion varies slightly, depending on whether the relationship between the root resource and the included resource is a "simple parent/child relationship", or a "named relationship".

Syntax for simple parent/child relationships

In most cases, the relationship between the root resource and an included resource is a simple parent/child relationship. Examples of this include:

  • An activity and its notes
  • An account and its AccountLocations

When using request inclusion for simple parent/child relationships, the JSON has the following structure:

{
  "data" : {
    "attributes": {
      ...
    }
  },
  "included": {
    "<resourceType>": [
      {
        "attributes": {
          ...
        },
        "method": "post",
        "uri": "/../this/..."
      }
    ]
  }
}

The data section

The data section includes information about the root resource, such as its attributes. (For PATCHes, the data section could also include a checksum value for the root resource.)

The included section

The included section consists of one or more subsections of included resources. Each subsection starts with the resource type name. Then, one or more resources of that type can be specified. For each resource, you must specify:

  • The resource's attributes
  • The method and uri to create or modify the resource.

The method and uri fields

Request inclusion involves a single call to a single endpoint. But internally, the system APIs use multiple endpoints to execute the call. For every included resource, you must specify the operation and uri relevant to that resource.

For example, suppose you are writing a POST /activities call to create an activity and a note for that activity. The note is the included resource. The included section would contain code similar to this:

"included": {
  "Note": [
    {
      "attributes": {
          ...
      },
      "method": "post",
      "uri": "/common/v1/activities/this/notes"
    }
  ]
}

This specifies that in order to create the note, use the POST /common/v1/activities/{activityId}/notes endpoint.

The uri must start with the API name, such as "/common/v1".

The uri must also specify the ID of the root resource. When the root resource and the included resources are being created at the same time, the root resource does not yet have an ID. Therefore, the keyword this is used in the uri to represent the root resource's ID.

Example of request inclusion for simple parent/child relationships

The following payload is an example of creating an activity on account pc:10, and a note for that activity.

POST http://localhost:8180/pc/rest/account/v1/accounts/pc:10/activities

{
  "data": {
    "attributes": {
      "activityPattern": "general_reminder"
    }
  },
  "included": {
    "Note": [
      {
        "attributes": {
            "subject": "Initial phone call",
            "body": "Initial phone call with claimant"
        },
        "method": "post",
        "uri": "/common/v1/activities/this/notes"
      }
    ]
  }
}

Syntax for named relationships

In some cases, the relationship between the root resource and an included resource is more than just a parent/child relationship. It is a "named relationship" in which the relationship has a special designation or label.

For example, every account has an "account holder". This is an AccountContact who is the legal holder of the account. An account can have any number of child AccountContacts, but only one of those AccountContacts can be labeled as the account holder.

When using request inclusion for named relationships, the JSON has the following structure. The lines that are not required for simple parent/child relationships but are required for named relationships appear in bold:

{
  "data" : {
    "attributes": {
      "<relationshipField>": "<arbitraryRefId>"
      ...
    }
  },
  "included": {
    "<resourceType>": [
      {
        "attributes": {
          ...
        },
        "refid": "<arbitraryRefId>",
        "method": "post",
        "uri": "/../this/..."
      }
    ]
  }
}

The data section

The data section includes information about the root resource, such as its attributes. (For PATCHes, the data section could also include a checksum value for the root resource.)

The data section also includes the field that names the relationship with the child resource. This field is set to some reference ID. The value of this reference ID is arbitrary. It can be any value, as long as the value also appears with the child resource in the included section.

The included section

The included section consists of one or more subsections of included resources. Each subsection starts with the resource type name. Then, one or more resources of that type can be specified. For each resource, you must specify:

  • The resource's attributes
  • The method and uri to create or modify the resource.

The refid field

Each included resource must include a refid field. This field must be set to the same arbitrary reference ID used in the data section. The system APIs use refids to identify which child resource in the included section has the named relationship with the root resource.

The method and uri fields

Request inclusion involves a single call to a single endpoint, but the system APIs internally use multiple endpoints to execute the call. For every included resource, you must specify the operation and uri relevant to that resource.

For example, suppose you are writing a POST /accounts call to create an account and an AccountContact who is the "accountHolder". The AccountContact is the included resource. The included section would contain code similar to this:

"included": {
  "AccountContact": [
    {
      "attributes": {
        ...
      },
      "refid": "...",
      "method": "post",
      "uri": "/account/v1/accounts/this/contacts"
    }
  ]
}

This specifies that in order to create the AccountContact, use the POST /account/v1/{accountId}/contacts endpoint.

The uri must start with the API name, such as "/account/v1".

The uri must specify the ID of the root resource. When the root resource and the included resources are being created at the same time, the root resource does not yet have an ID. Therefore, the keyword this is used in the uri to represent the root resource's ID.

Example of request inclusion for named relationships

The following payload is an example of creating an account and an AccountContact for the account whose relationship is "accountHolder". (Accounts also require a primary location, so the payload also create an AccountLocation whose relationship is "primaryLocation".) For more information on creating accounts, see Creating an account.

POST http://localhost:8180/pc/rest/account/v1/accounts

{
  "data": {
    "attributes": {
      "accountHolder": {
        "refid": "newperson"
      },
      "organizationType": {
        "code": "individual"
      },
      "preferredCoverageCurrency": {
        "code": "USD"
      },
      "preferredSettlementCurrency": {
        "code": "USD"
      },
      "primaryLocation": {
        "refid": "newloc"
      },
      "producerCodes": [
        {
          "id": "pc:6"
        }
      ]
    }
  },
  "included": {
    "AccountContact": [
      {
        "attributes": {
          "contactSubtype": "Person",
          "firstName": "Bill",
          "lastName": "Preston",
          "primaryAddress": {
            "addressLine1": "2850 S Delaware St #400",
            "city": "San Mateo",
            "postalCode": "94403",
            "state": {
              "code": "CA"
            }
          }
        },
        "method": "post",
        "refid": "newperson",
        "uri": "/account/v1/accounts/this/contacts"
      }
    ],
    "AccountLocation": [
      {
        "attributes": {
          "locationCode": "0001",
          "locationName": "Location 0001",
          "nonSpecific": true,
          "postalCode": "94403",
          "state": {
            "code": "CA"
          }
        },
        "method": "post",
        "refid": "newloc",
        "uri": "/account/v1/accounts/this/locations"
      }
    ]
  }
}

Additional request inclusion behaviors

PATCHing and POSTing in a single request

When you execute a POST with request inclusion, the operation for each included resource must also be POST.

When you execute a PATCH with request inclusion, the operation for an included resource could be either POST or PATCH.

  • If you want to modify an existing resource and create a new related resource, the included resource's operation is POST.
  • If you want to modify an existing resource and modify an existing related resource, the included resource's operation is PATCH.

Requests succeed or fail as a unit

When a POST or PATCH uses request inclusion, it is possible that there could be a failure either of the operation on the root resource or the operation on any of the included resources. If any operation fails, the entire request fails and none of the objects are POSTed or PATCHed.

Included resources cannot reference resources other than the root resource

When using request inclusion, each included resource must specify its own operation and uri. The uri is expected to reference the root resource using the keyword this. This ensures that when the included resource is POSTed or PATCHed, the included resource is related to the root resource.

For example, suppose a POST is creating an account and an AccountContact. The uri for the Accountcontact would have a value such as "/account/v1/accounts/this/contacts".

From a syntax perspective, you could attempt to attach an included resource not to the root resource, but rather to some other existing resource. For example, instead of referencing the root resource, the uri for the AccountContact could reference an existing account, such as "/account/v1/accounts/pc:20/contacts". This uri says "create an AccountContact and attach it not to the root resource of this POST, but rather to the existing account pc:20".

The system APIs will not allow this. Any attempt to POST or PATCH an included resource to something other than the root resource will cause the operation to fail.