Ed-Fi API resources have two overlapping key systems. This section describes the structure of the different systems along with detail about how and in what circumstances API clients interact with each.
...
In the API, Ed-Fi API resources are assigned a resource ID by the API implementation. This value is defined as a UUID. This ID must be unique with the API scope, but it is not guaranteed to be a GUIDThe identifiers could be generated using a UUID (universally unique identifier) implementation like Microsoft's GUID (globally unique identifier), this identifier should be generated by the Ed-Fi API and not assigned from an external source and it will never change.
This ID helps provide for compatibility with REST conventions. For example, a CourseOffering can be looked up/queried by doing a HTTP GET on a path like this:
...
The resource ID is API assigned and can't be requested.1 Further, if a HTTP PUT POST includes such an ID that ID will either be ignored or result in an error - in either case, it should not be included!
When an element is POSTed (created) the resource ID is provided via a HTTP Header. It will look something like this (note that this is a sample, and specific values will vary):
...
Natural Keys
...
To improve data quality and maximize the possibility for data to move between systems, an Ed-Fi APIs data model also employs a natural key system.
The key for an entity can be looked up by using the either the Ed-Fi UDM Handbook v2.2 and Unifying Data Model - v4.0 Handbook or the Unifying Data Model - v5.0 Handbook and looking under the column “Identity” – key fields are indicated there. For example, for the CourseOffering entity, this page appears:
...