...
In some circumstances, this pattern can also be used to aggregate information from multiple Ed-Fi API deployments. However, this should only be done in a context where uniqueness of certain identifiers can be guaranteed. For example, when retrieving student data, the StudentUniqueId must be unique across all related source systems. This may be feasible when all of the source systems are in the same state, and the state education agency (SEA) has a strong state-wide unique identifier system in place. The EducationOrganizationId values (such as LocalEducationAgencyId and SchoolId) would also need to be unique across these source systems.
Specialized Ed-Fi Resources with Duplicate Data
...
This is an emergent Ed-Fi specific pattern. The Ed-Fi Alliance would appreciate hearing feedback from anyone who takes this approach.
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
How it Works
A new domain can be added to the Ed-Fi API, which describes or a new shape entity can be added to an existing domain. The new entity/entities describe new shapes for data that already exist in one or more other domains in the Ed-Fi API. In effect, this creates a specialized API specification, which could be following either the backend-for-frontend or central aggregating gateway pattern. For example, the Enrollment API could be rebuilt as a new domain in the core Ed-Fi Data Standard.
...