MedBiquitous Technical Steering Committee
October 11, 2017
Attending: Sascha, Jon, Joel, Scott Kroyer
1. Comparison of JSON API and OData for usage by MedBiq API specifications
Sascha noted that he wanted to follw th ebroader trends of our vendor community, but didn't have a sense of that. Joel noted that in our early standards work, we looked at what kind of technology our members had. Our smaller members did not have much in the way of middleware and such. For APIs, is that still the case? Are heavier hitters worrying about APIs?
Sascha replied that he hadn't seen huge change. They have limited resources and limitations on the complexity that can be thrown at their systems. They do see a demand for simple common REST APIs via tools like Tableau or Microsoft BI to draw data quickly. They want to draw JSON data without having to work in the web toolkit. Joel noted that for Curriculum API, hosters would be univesities? Valerie noted the would be tools, not universities. Scott noted they are not using either JSON API or ODATA for their implementation. Joel clarified they coded straight to REST. Scott clarified their existing implementation is not API based. the new one will be REST based. Haven't considered ODATA or JSOn API yet - just doing free form JSON. They are moving into standalone microserves that will need to interact and looking at ways to abstract them. using free form JSON approach will lead to problems, so they will start to look at more metadata in JSON. He leans away form ODATA, had bad performance with an experience last year. They will have to provide more in the data contract. Joel asked if he had problems with the tools or the spec. Scott commented the problems may have been mischaracterized. Possible that the performance problem related to an underlying problem.
Joel noted the other thing to consider is that our architecture allows for XML and JSON. Sounds like Ilios is pure JSON implementation. APIS transferring parts of MedBiquitous documents might be XML, new things might be JSON, others might be both.
2. Possibilities for referencing one or more such specs from our API Architecture
3. Planning future activities, including discussion with the AAMC on federated identity