...
Info |
---|
To be published on Exchange/public community documentation |
What is "API Parity"?
The goal of Meadowlark is to able to "fool" a current API client: to be able to substitute the Ed-Fi API provided by Meadowlark with the API provided by the Ed-Fi ODS/API and have API clients continue to function/not realize that they were communicating with a different API. We refer to this as "API parity."
Broadly speaking, API parity was achieved, but there were some gaps. These gaps could be closed, but in each case the project chose not to do so. This document provides a list of the known gaps to API parity, and explains why the gap was left in place.
Will these gaps be closed?
Some may, but it is unlikely that all such gaps will be closed. Ed-Fi is an both an effort to build open source data infrastructure AND an effort to provide blueprints for standardize data flows. In respect of the latter goal of standardization, it is highly useful to compare API differences across API implementations.
Rather than try to close all these gaps, the goal should be to clearly define what API features are required and which should be allowed to vary. Doing so will allow for the development of alternative API implementations, whether through the open-source effort of the Ed-Fi community or through efforts independent outside of that community work.
List of API Parity Gaps
Gap | Support for "link" objects in JSON | |||||
---|---|---|---|---|---|---|
Description | In the ODS/API, the JSON is annotated by "link" elements that show the path to the element using a GET by the resource ID. These elements appear like this:
These elements do not appear in the GET elements provided by Meadowlark. | |||||
Likely direction | It is unlikely that these will be supported, and in general the direction is to continue to omit these from Ed-Fi API specifications.
|
Support for "discriminator" fields on "link" objects