PATCH /scim/v2/Me endpoint is used to add, modify, or remove one or more specific attributes from the currently authenticated user. Unlike
PUT, a complete representation is not specified.
PATCH requests always include an
Operations attribute, which is an array of the changes to make.
|schemas||array||yes||The SCIM schema of the session resource. Always has the value urn:ietf:params:scim:api:messages:2.0:PatchOp.|
|Operations||array||yes||An array of modification operations to perform on the resource.|
Each modification operation contains the following fields:
|op||string||yes||Specifies the type of modification. Valid values are add, remove, and replace.|
|path||string||The attribute path targeted by the operation. If unspecified, then the root of the resource is targeted. To target a specific member of a multivalued complex attribute when performing a replace, the attribute path may include a filter, such as addresses[type eq “work”]. A sub-attribute may be targeted using a dotted ‘attribute.sub-attribute’ notation, such as addresses[type eq “work”].value.|
|value||any||The attribute value to set when the op value is add or replace. May not be provided when the op value is remove. Any SCIM data type may potentially be used; the validity of the value is dependent on the path.|
The combination of
value gives the client a tremendous amount of expressive power in forming varied modification requests. Because the path used may potentially select any node of the resource, the client must take care to specify a value of the appropriate type. For example, the path
addresses[type eq "work"] selects the member of a multivalued complex attribute, so the corresponding value must be an object. The path
addresses[type eq "work"].value, meanwhile, selects a specific sub-attribute of the same object, and its corresponding value must be a string.
PATCH request format is described in detail by RFC 7644.
The sample replaces the value of a sub-attribute of a complex attribute.