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:
- Split account from profile, or use one endpoint?
- 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."
- 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.
- 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)