PATCHes in request inclusion

When using request inclusion, you can PATCH both root and included resources.

When PATCHing root resources using request inclusion, payloads generally have similar structures to POST payloads. For more information on payload structures, see Syntax for simple parent/child relationships and Syntax for named relationships.

However, when PATCHing, the uri field for included resources is treated differently from POSTs.

The this keyword is invalid when PATCHing

The this keyword is a placeholder that is only used when the id of the root resource has not yet been generated. If the root resource is being PATCHed, its id has already been generated, so the use of this results in an error.

PATCHing parent and POSTing child

Here is the basic syntax for PATCHing a parent and POSTing a child.

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

PATCHing parent and PATCHing child

Here is the basic syntax for PATCHing a parent and PATCHing a child.

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

Note: The uri field may or may not include a placeholder for the parent id. It depends on the structure of the endpoint the uri is referencing.

For example, if the children were a PATCHed contact on an account and a PATCHed note, the uri fields would be:

"uri": "/account/v1/accounts/<accountId>/contacts/<contactId>"
"uri": "/common/v1/notes/<noteId>"