TAG Meeting 2021-03-31 - Subgroup to Review Validations API Design
Materials
Participants
Notes
The meeting reviewed the Ed-Fi Validation API Design document. The architecture document was not reviewed.
The design envisioned was to create a set of API resources that work like the current Identity API: the Ed-Fi ODS provides the signature for the API (and represents that in Swagger metadata, etc.) but requests are routed to a local service that provides the response, which is then routed back to the client. The Alliance also surfaces the API as a formal community specification.
The vision is that the validations data storage (at least in this initial variation) is therefore NOT in the ODS database.
Some discussion points:
EducationOrganizationId needs to be required in order to support authorization coordination across multiple districts / SIS systems (DONE - changed this in the document)
The initial use case should make these assumptions:
Only validation results from the most recent run are maintained/published. There was much discussion on this question, and it was generally agreed that this could evolve to the API providing some history, or perhaps clients would keep a history. At any rate, the simplest starting point seemed to be to replicate current processes, which seem to be to wipe out/replace older results with newer ones.
All validations rules are run with each run. This seemed to be the dominant pattern currently in the field.
Filtering needs for GET requests for results were also discussed as important. The details on this were generally left for the initial implementation to work out, but EdOrg filtering was needed at a minimum.
The possibility of a summary API or aggregate counts were discussed. This was seen as possibly valuable, but not clearly needed for an MVP.
The question of a means to expose "longstanding" issues or information on which issues were "resolved" or "unresolved" issues was discussed extensively.
To some extent, the decision to re-run everything every night and wipe out old results makes this not part of an MVP - the API simply won't have the history or data to offer such info.
However, the design itself includes the concept of a "signature" that can possibly be used to construct such intelligence on the client side (see the API document), so there is a possibility of the client doing this
The possibility of an API that could also show "root cause" was also discussed.
An example: a SIS attempts to enroll 400 students into a school, but the school has not yet been loaded, so there are 400 errors. A "root cause" capable system might just generate 1 error, or at least aggerate/summarize up to an additional "root cause" error
Useful, but generally seen as not MVP and something that would be evolved over time.
Actions
Eric to raise a ticket on the Identity API work to get a sense of what this would take to implement and who would be able to do this. - DONE - see
ODS-4918 - Getting issue details... STATUSEric to bring back to the TAG to over review for LEA use cases