TAG Meeting 2017-02-01
Participants
Mark Reichert
Matt Warden
Don Dailey
Geoff McElhanon
Eric Jansson
Chris Moffatt
Notes
Powerpoint deck included below. Main goal was to review the proposed changes to the Ed-Fi ODS APIs, and get the TAG's feedback. Changes made would be released as part of ODS 3.0.
Topics included (from slides):
Distinguish extensions from core and introduce namespaces
Was not discussed, as has previously been discussed by TAG at several times.
Change API semantics for GET to always return collections
Breaking change for some integrations if they rely on natural key lookups
ODS team is currently FOR making this change
No reasons not to make this change were raised
Support for PATCH
Non-breaking unless PATCH already implemented (not a problem for MI because the semantics are built into the SDK)
Not specifically targeted for ODS 3.0
The proposed IETF model was not specifically discussed
No reasons not to make this change were released
Changes to API security
Also under consideration by ODS team, but no clear recommendation there yet
It was pointed out that the main benefit is that OpenID Connect tokens can hold claims, so this will reduce round-trips to query authorization databases every time (the Admin DB in the ODS) - this was not mentioned in the slides originally.
The topic of user-level auth was raised, and it was clarified that the Ed-Fi Technology Roadmap does not include adding support; however, experiences with the Ed-Fi Dashboards suggest some utility here: the Dashboards replicate authZ functionality of the ODS, which seems inefficient.
“Un-flattening” API resources
ODS team is leaning towards 'NO' on doing this, and the TAG members who spoke agreed: without a clear benefit we should not do this, as it would break lots of client code.
Changes to Type APIs
It was brought up that Descriptors APIs have the same problem and should be included.
TAG members voiced concern over the confusion in the ecosystem caused by a mismatch between the UDM specs for Descriptors and Types and their implementation in the APIs. There was agreement that this change is important, even though it will break, as not fixing this will continue to propagate non-standard practice.
Change rules around removal of prefixing in API fields (not in slides, but raised at meeting)
There is a possibility of restoring field prefixes that are dropped in the APIs, as in 'AssessmentForm' (UDM) -> 'Form' (API)
This would bring some small benefits in terms of semantics of the API and consistency with UDM, but it would break much client code. Members recommended not doing this, as there is no clear driving benefit.