Attendees: Ferdi, Steve Magoun, Matt Drayer, Andy, Christina, Piotr, Nimisha, Ned, Leslie
On Hangout: Dave O, Jim A, Vishal.
Clarifying questions:
- Is this already in master?
- Parts are, yes: Account, profile, at v0
- Other parts are not: Preferences
- Deliverables being built by Arbisoft on this API for delivery later this month.
- Considering it's already in master, what is the goal of this meeting?
- review the design, make sure it's what we want. Figure out how we can get to what we want.
- Privacy: who should be able to call these methods, and what information can they get?
- Why separate accounts from profiles?
- Your profile is something you are building to share, based on info in the account (except for pic and bio, which aren't in the account).
- Didn't want to tie profile directly to the info in the database.
- wanted it to be a "virtual" view of the data.
- All info about account is available through the account endpoints
- Everything is set through account, profile is readonly.
- Shouldn't that be a reason to keep only one, and get rid of the other?
- the Profile endpoint serves the new profile page
- anyone can view your profile page, but they can't view your account.
- the APIs mirror that.
- Can't we do that with authorization on top of a single endpoint?
- I can patch my account, others cannot, but everyone can read.
- Can't we do that with authorization on top of a single endpoint?
- Is there a point later where profile has information that account doesn't?
- One idea that hasn't been fully explored: course-specific fields in the profile.
- Some things might be on the profile that don't come from the account:
- courses you've taken, badges.
Concerns:
- Privacy:
- who should be able to call these methods, and what information can they get?
- Global "Staff" users: they have access to everything, including updating!
- Too many people have is_staff.
- is_staff should be enablable, not always enabled.
- Why do staff need to change user account information?
- Maybe we should leave out the is_staff ability?
- be safe now since we don't have a use case for the API to provide is_staff to change anything.
- perhaps a sudo=True flag in the API?
- What are the negative consequences if we start conservatively?
- We aren't building UIs that would make use of the is-staff access now.
- MITx needs read access, but not write for their scripting.
- Too many people have is_staff.
- DECISION: disallow is_staff write access for now. We'll learn more about what people want from it.
- Split account from profile, or use one endpoint?
- Preferences: could they be folded into account API?
- Christina: We don't want to name all of the possible preference keys
- Ferdi: this would reduce the number of API endpoints.
- Ferdi: the preferences endpoints don't feel resource-based.
- Ferdi: don't have a /preferences endpoint, just get the user object and it will have preferences on it.
- Nimisha: criteria:
- if the bulk of the payload could be an issue, then /preferences could be separate to reduce size of payload
- if you want to query preferences, a separate endpoint would be useful.
- Piotr: I have enough "I don't knows" that I prefer one endpoint rather than three
- How will microservices affect this decision?
- It's odd that /profile can't accept a PUT, and to change the information, you PUT on /account.
- Authorization will be trickier if you combine the endpoints.
- Fewer, larger endpoints vs more, smaller endpoints
- Dave prefers smaller
- Christina prefers smaller
- Nimisha thinks preferences should be separate, but accounts and profile seem too similar, and should be combined.
- Ferdi wants to combine preferences into accounts.
- Preferences: could they be folded into account API?
- API could get confused once things happen:
- Per-course profiles
- Integration with XBlocks
- Other platforms using XBlocks may not use the same fields we do.
- Namespace prefixes could help.
- preference for "edx." over "edx-platform."
- Can't we use absence of namespace to mean "edx"?
- This API is particular to edx-platform, so why prefix the fields with "edx-platform"?
- It's confusing if things have different names in different places. (XBlock user service vs. this API)
- Is this a concern for every API we build?
- No: user information is so broad, it needs prefixes.
- Does account vs profile interact with this concern?
- account can be very edx-specific, while profile could be more generic?
- How will we support other profiles in the future? (Facebook, Google, etc)
- Vishal: by default, the user's profile is public?
- the default is configurable by site operator, and the "profile fields" are also.
- for edx.org: default visibility is all users
- Growing number of APIs operating on the same resource. ANSWERED.
- Everything in the user_api django app will be refactored into the new APIs, or delegating to.
- (Except a few that aren't in the new API, like email_opt_in preferences, controlled by individual URLs)
- Does this API provide for modifying roles? ANSWERED.
- This API doesn't provide for course settings like TA roles.
- Authorization is a separate service.
- Role information is per-course.
- Is there anything in this API that is per-course?
- Not yet, but a user/course combined id could support it.
- Authentication/Authorization
- We have both oauth and session authentication.
- How would someone write a script against this API?
- The script would use OAuth2.
- Profile search: a logged-in user will be able to search profiles.
- Can we prevent people from scraping all the public profiles? ANSWERED.
- Not really, other than rate-limiting, terms of service, etc.