Clinton, Carson, Brandon, Nimisha, Dave O, Miki, Peter, Piotr, Ned, Cale, Ed, Jim, Vishal, Matt

Deltas from last time:

• stripped out all the content APIs

• structure is a json object mapping ids to block structure data, children is a list of ids

  • why isn't it hierarchical?

    • flat is more application-agnostic

    • tree might not be general enough, if the course is a dag.

    • even orphans can be listed with a flat structure.

• authentication hasn't been discussed

  • dedx is moving auth components to a separate repo

• authorization

  • anyone can look at any course

  • the api will be publicly exposed

  • don't mobile app users have an oauth token?

  • clinton will be dealing with permissions.

  • MUST: be sure an oauth2 token isn't enough to access all courses.

The internal API (a method on modulestore returning JSON) is needed, but isn't meant for wide use

• MUST: Add to the docstring, explaining all of the downsides, and the appropriate use of this method.

Content versions?

• This only provides the published version.

  • For analytics, they will need to report on out-of-date content, so versioning must be accommodated somehow.

  • versions have to be exposed throughout the system.

Detail questions:

• The blocks are in the "blocks" object under their usage key, and then have the key as "id" in the block itself.

• The blocks have "type", what about "category"?

  • "category" is old, we prefer "blocktype"

• Why is depth=2 included?

  • oversight, that is going away.

• Will this be in Birch?

  • no.

Everyone is OK with this going forward.

Course API Unification

• Not enough detail to code to yet.

• Dave was trying to flesh out a scheme for layering APIs

• Content-based vs Discovery-based: did that make sense?

• Dave: what would be sufficient detail to make a decision?

  • Where do we plugin our API?

  • Guidelines about where an API should live.

  • Everyone wants to know what the whole namespace looks like,

  • and what the rules are for adding to the namespace.

    • for example, "this part of the namespace needs to be highly performant"

  • Guiding principles for API in general.

    • There's a doc growing these guidelines

    • deliverable by the end of this month.

    • bring that to arch council

• Deployment? Resident in LMS always?

  • API/process is not 1-1

  • Moving more toward a model of process components that host multiple APIs

• Discovery layer?

  • Yes, we need to think about service discovery.

  • People have floated ideas, but no one has gotten to the point of a proposal.

  • We will favor having small APIs

  • Central discovery will be important, but we don't know enough yet.

  • There will be a number of deployment use cases to solve

    • token storage

    • rate limiting

    • monitoring

• What does Dave want other people to think about?