These API operations are used to send SOR information to the Identity Registry
TBD: Create Swagger Specification for These Operations
SOR Person Role Added
It is up to the Identity Registry to determine how to map the provided attributes to its internal data model.
In these examples, hrms is the SOR, X12345 is the SORID, and R98765 and R98766 are SOR Role IDs. The SOR Role ID must be unique for the SOR Person, but need not be unique across all SOR Roles.
Request Using Separate Person-Level and Role-Level Attributes
PUT .../v1/SorPeople/hrms:X12345 { "sorAttributes": { "names":[ { "type":"official", "given":"Pat", "family":"Lee" } ], "dateOfBirth":"1983-03-18" } } PUT /v1/SorPeople/hrms:X12345/Role/id:R98765 { "sorAttributes": { "title":"Professor of Phrenology" "percentTime":"50%" } } PUT /v1/SorPeople/hrms:X12345/Role/id:R98766 { "sorAttributes": { "title":"Administrative Assistant" "percentTime":"20%" } }
Response
Response | Description |
---|---|
| Request successfully processed |
| There was a problem with the data submitted |
| Authentication required |
| Client is attempting to operate outside of its authority (eg: to the wrong SOR path); Optional – server may return |
| Unknown error |
The Identity Registry may return a Reference Identifier if identity match is not called separately. (The other ID Match responses may apply, as well.)
201 Created { "referenceId":"M225127891" }
Additional attributes, such as identifiers, may also be returned, or may be returned instead.
201 Created { "referenceId":"M225127891", "identifiers":[ { "identifier":"pl53", "type":"network" } ], "emailAddresses":[ { "address":"pat.lee@university.edu", "type":"official" } ] }