In June 2015, members of the Ed-Fi Community gathered in Austin to discuss strategies to accelerate data exchange between systems using Ed-Fi standards. This meeting, titled “Vendor-to-Vendor Data Exchange,” ultimately recommended simpler, more use-case focused options as a key strategy moving forward.
As a direct result of actions taken at that meeting, Ed-Fi published its first APIs in mid-2016. These new APIs are called “composite” APIs because they “compose” (or aggregate) data elements across multiple discrete entities in the Ed-Fi data model. Such APIs are also use-case focused and read-only.
Those familiar with the initial set of Ed-Fi ODS 2.0 APIs will understand that the 2.0 APIs are quite granular, and are intended for a source system to manage data on a target system transactionally. That is, a vendor system uses the ODS 2.0 APIs to write individual changes to the target system (the Ed-Fi ODS) usually in near real-time (transactionally). For example, an individual student enrollment in a class section today often posts from the SIS to an ODS in Ed-Fi format just minutes after the enrollment occurs in the SIS. We sometimes refer to this kind of API as a “transactional synchronization” API.
While a granular, transactional API called by a source system to synchronize data is great for some use cases, it is less well suited for others. This was in-part the conclusion of the 2015 meeting. In many cases, a target system wants to initiate a transfer of data on demand from a source system. Such a system is more suited to systems preferring periodic bulk updates rather than live updates and allows the target system to control the data flow.
Accordingly, the Ed-Fi Alliance published two, new read-only “composite” APIs – an Enrollment API and an Assessment API – as part of the Ed-Fi ODS / API v 2.1. The design of these APIs relied on the Ed-Fi data model for the JSON resource structure, as well as further interviews and research with field implementations, to help determine which paths and aggregation of entities worked best. The results were then vetted via the Ed-Fi Technical Advisory Group.
In addition to the ODS implementation, the Alliance also published specifications for these APIs as public Request for Comments in order to support the vision that they would serve situations where an Ed-Fi ODS / API could not be utilized.
Check out the links below to find out more about each of the APIs discussed above and feel free to leave comments on what you see. As we await field implementation and community feedback, we would love to hear your thoughts on our work!
A big thanks to the many community members who dedicated themselves to these programs.
