/
2015.01.20 Course Information API

2015.01.20 Course Information API

Jan 20, 2015

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?