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?