TAG Meeting 2016-04-06

Participants

  • Erik Gomez
  • Matt Warden
  • Neal Schuh
  • Josh Klien
  • Richard Charlesworth
  • Brittany Blaze, YES Prep
  • Mark Reichert
  • Chris Voss
  • Arley Schrock, TN DOE
  • Don Dailey
  • Mark Walls
  • Chjris Moffatt
  • Eric Jansson

Notes

The meeting was about the Ed-Fi APIs, both as elements of the Ed-Fi ODS and as future API standards.


The first topics concerned how to handle extensions. The current ODS API extension model (see the attached document, slides 2-3) creates some confusion in the ecosystem as resources and resource fields occur without any indication that they are extensions. A few ideas proposed in previous meetings were discussed (slide 4). Pros and cons were discussed, and it was generally agreed that the stronger model was to have an reserved element name that references an object that includes extensions, and does so according to a registry system (option 3, with option 2a being the second best). The first option (place API extensions at an alternative path/URI) was seen as possibly having one distinct advantage in that it allowed for easier rollout of extended resources over time to a vendor ecosystem , but was also seen as inefficient, requiring additional transactions to update resources.

On the registry specifically, one piece of advice was to look at the NPM JavaScript registry as an example to follow.


The next topic was about concerns over having a generative API functionality as part of the Ed-Fi ODS, which could result in multiple APIs. This was indeed seen as a risk by all who offered opinions, as multiple APIs that differ in even slight ways increase the costs of API integrations. It was agreed that part of the hard work is in defining and sticking to a standard, even if that standard is more limited.

Materials