Child pages
  • 2017-10-11 TSC
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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 follow the broader 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. V noted xAPI does not use either. Joel commented most APIs don't use either. Complexity may be addressed through other infrastructure. but toolkits can make APIs easier and more consistent. Jon agreed many APIs stumble into these; it's way Ilios did. Other things they were using used JSON API. other groups may be doing the same. They use a javascript framework called ember, and that uses JSOn API to communicate to browser. New york Public Library and uses json api. Ruby on rails, too.

Joel noted that based on scenario gathering, is accredited, and answer may be yes or no, we want to be non-burdensome. But we also want to give direction to larger APIs with big aggregations where you need to navigate the structure behind the API. That's where JSON API is useful. D not like that JSON API created their own content types. It screws up people doing multipel content types. Jon noted you can send multiple content types with the request. It shouldn't interfere with XML. Joel noted the json api media type is required.Jon rpelied to get json api back, you need to send that  content type. You can indicate yu want json xmo or jsn api, and allow content negotiation to handle. Scott note that for things that are eventually boolean responses, an API for that should be structured so that resource requested is certification. response is no response body, either 200 or 404. OK or not found. Jon agreed. Valerie noted there would likely be more data. Scott commented you could send more data, but not certified would be a 404.

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 

  • No labels