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
- 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.
- 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.
- 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?
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
- What does Dave want other people to think about?