This advice is most important for data providers and publishers, rather than data consumer or readers.
As a data provider, your system's users will not always want to provide all data as part of a regular or periodic data exchange. To avoid oversharing data, provide some kind of user-friendly interface or tool that allows your system users to select which data should be sent to an API. Because API exchanges are generally regular, this configuration info should generally be captured and re-used.
...
Rather than defaulting to all data being exchanged, your Ed-Fi integration should allow the users to select which API resources should be shared as part of the data exchange. API resources should be turned off and require a clear and deliberate action by a user with the proper authority to enable them. This helps ensure that your systems's user is making an active choice to
...
push the data
...
and is authorized to perform that action.
...
Additionally, the user should be notified if the configuration will cause synchronization problems due to dependency order inherent in API resources.
The specific use case should be considered as well. For example, if a system integration will be supporting programs only at certain schools
...
, then the API client should allow the configuration to be restricted in this same
...
manner – to particular schools.
Note: The data consumer has similar responsibilities and should also restrict access accordingly.
...
This promotes data security and reduces labor when tracking down problems with data quality and performance. Further, it sets up the customer for success in the configuration of the product in their implementation.
Ed-Fi's ODS/API technology also allows for the ODS/API to be extended. To learn more about why you would do this and how, refer to API Extensions