...
It bypasses the authorization security in the Ed-Fi API, potentially affecting both read and write operations.
This approach may put too much strain on the primary data storage, causing resource contention for other Ed-Fi client applications that are using the Ed-Fi API.
The Ed-Fi database structure is not a standard. Thus, different implementations or even different versions of the same implementation could have unstated breaking changes at the database layer. For example, the Ed-Fi ODS/API Platform and the Ed-Fi Data Management Service (unreleased at the time of writing) https://edfi.atlassian.net/wiki/spaces/ODSAPIS3V72/overview and the Data Management Service Platform have very different backend database structures. An integration built on the ODS/API’s
EdFi_ODSdatabase would not be compatible with the Data Management Service’s database.
...
Caution: If this integration is intended to access read data from the Ed-Fi API that were sourced from a different system, then real-time integration might not be feasible. Check to see if the other source system(s) have real-time or batched integrations. If notbatched, then help the end-users adjust their expectations about data freshness.
...
Ed-Fi API client credentials will need to be managed directly in the backend application. The client_id and client_secret should be secured as strongly as one would secure credentials to a backend database.
...
If satisfying the frontend requirements only requires storing hundreds to thousands of records, it may be feasible to perform a full refresh of the data on a schedule. As the number of records to retrieve increases, a full refresh will take longer and can put significant strain on the Ed-Fi API. In such cases, the Change Queries API can be used to detect deleted records and to look for new or updated records.
...
Frontend API Design Patterns
| Anchor | ||||
|---|---|---|---|---|
|
Coming soon
Row Level Authorization
| Anchor | ||||
|---|---|---|---|---|
|