edX: Clinton, Nimisha, Gabe, Ed, Piotr, Chris Dodge, Steve Magoun, Miki, Matt, Cale, Dave Ormsbee
MIT: Ferdi, Peter, Carson, Brandon
- Piotr: Using it for meta-data is fine, but to get children, access videos, etc, the semantics haven't been thought through
- those APIs should exist, we already have OLX that handles the full messiness of the course structure.
- Ferdi: OLX is heavy to get anything less than the whole course.
- those APIs need to be driven by use-cases, and must be unambiguous.
- Miki: OLX isn't a transport API, and Clinton has use-cases.
- possibility: scale back the API to do just what Analytics needs
- or, develop the use cases so we can fully develop the API
- Clinton: "Within insights, we need course metadata, the course name, and the course structure for answer distribution."
- from assignments, drill down into problems and problem parts.
- Insights is using ...?
- Question: for A/B-tested gradable content, what will the API produce?
- Insights would want both paths of the A/B-test
- Transport vs storage representation:
- transport APIs don't need to mirror the storage representation of an object. The API may need a more compact representation, for example.
Clarification: this API does not provide a student-based view of a course.
MIT has a course import/export API that does take the student's view into account. That API hasn't yet been reviewed by Architecture Council, but it's in a PR.
Can the namespace be changed to narrow the focus to just Insights?
Is this API too specific to be a public API?
How narrow can the API be?
- Insights needs:
- Course name and id
- The course structure, just enough to populate a tree of gradable content
- The mobile API provides some of this already,
- but only for a particular user
- Subsetting of the API
- Mobile and Insights need different fields returned
- But over-optimizing by filtering can wait.
- CourseInfo API from Dedx also exists.
API Catalog: there is one on the public wiki. Does it include in-development ones? Yes.
Peter: How does this API deal with split and versioning?
- presumably without a version number, you get the latest.
Matt: the Solutions team started work on an API like this almost a year ago, and there's not much more clarity now than there was then.
- How to let teams splinter off to get features built, while still making progress on the public API supported by use cases?
- Who is the product owner for the public API?
- API proliferation: How do we decide how many APIs, and how finely to slice them?
- APIs: Insights, Mobile, Course Catalog, Solutions.
- Clinton and others will have to huddle to decide
- How does the API deal with versioning?
- How does this API deal with the unknown variety of XBlocks and content?
- How can the Analytics team move forward with the consumer of this API?
- there are tactics we could use to let the team build the client without a public API on master.
Small team to follow-up:
- Clinton, Dave Ormsbee, MIT rep, Piotr, Matt
- What do the course APIs look like?
- How does Analytics land?