Proposal: Add /me endpoints to student and instructor APIs

[thomasplevy]

In following with the WP Core (and many other APIs), I'd like to open a discussion around adding /me endpoints for the existing student and instructor API groups.

After building the Groups add-on using almost all onsite user interactions through the REST API, I'd like to move into using our own internal REST API to power more of LifterLMS itself. Initially I thought we'd use the REST API to power things like reporting screens on the admin panel only, but now I'm thinking that we could use the REST API to power enrollments, notifications, course progression, user information updates, and more.

We can do all of this with the current (and planned) APIs, all we need to do is localize a JS script with the current user's ID via PHP and pass in the user ID to all our JS.

However, adding /me endpoints would make this (somewhat hacky) localization unnecessary and allow us to simply code /me into JS files that utilize our own API, ensuring that we always make requests to the current user.

The following endpoints could be implemented (mimicking the behavior of the existing $id endpoint):

Retrieve current instructor: GET /instructors/me
Update current student: POST /instructors/me
Retrieve current instructor's content: GET /instructors/me/content

Retrieve current student: GET /students/me
Update current student: POST /students/me
Delete the current student: DELETE /students/me -- Note that actual students with the student role cannot actually delete themselves. This should be noted in documentation!

Retrieve current students enrollments: GET /students/me/enrollments
Retrieve current students enrollment in a post: GET /students/me/enrollments/{post_id}
Create, update, delete student enrollments: POST/PATCH/DELETE /students/me/enrollments/*

• Note that students cannot create, update, or delete their own enrollments in most cases. WP core caps/permissions should take care of this but we should take caution to ensure that student users cannot bypass ecomm/enrollment forms with this endpoint.

Retrieve current student progress in a post: GET /students/me/progress/{post_id}
Update current student progress in a post: POST /students/me/progress/{post_id} -- Some validation should exist here:

• Only allow students to objects as complete if they can access the object. THey must be enrolled, must have completed prereqs, the object must be available via drip, etc...
• Only allow marking completed objects incomplete if the LLMS core setting to mark things incomplete is enabled
  Delete student progress DELETE /students/me/progress/*
• Student's cannot delete their progress (but they can mark things incomplete, conditionally) - but an admin could delete their own progress

[eri-trabiccolo]

I missed this, I like it!
We might even implement those endpoints that you said we shouldn't. Even if I see what you mean, the underlying checks on the WordPress capabilities will actually take care of allowing those kind of actions, don't you think?
I mean, if I'm an administrator why can't I delete my enrollments/progresses through the */me/* endpoints? I will be totally able to do it through */{myid}/* endpoints.
What do you think?

[thomasplevy]

@eri-trabiccolo

I see what you're saying and I suppose you're right but I was thinking it would be unnecessary to write the additional endpoints geared at a student who generally cannot do that but that does actually assume that all students are of the student role (which is not the case)

Okay!

[thomasplevy]

I've edited the initial proposal to include the things I initially said should be excuded