Attendees:

edX: Clinton, Nimisha, Gabe, Ed, Piotr, Chris Dodge, Steve Magoun, Miki, Matt, Cale, Dave Ormsbee

MIT: Ferdi, Peter, Carson, Brandon

Issues:

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?

ISSUES:

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
Deliverables:
- What do the course APIs look like?
- How does Analytics land?

Browser not supported