2015.01.20 Course Information API


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