API draft spec for ceo #1
Labels
No Label
priority
high
priority
low
priority
medium
priority
very high
BUG
Feature
High Priority
Low Priority
Medium Priority
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: public/pyceo#1
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Here is a draft proposal for the new ceo API spec:
Last Update: 2021-08-18
Please leave your feedback in the comments.
We should add password resets and changes, and automatically generate secure passwords for those and on account creation. We can also use only one HTTP method per endpoint to make things clearer. Here's my proposal:
At first glance these are my comments:
Members
I would probably change
to
(you would need to restrict which fields can be changed by admin and/or non-admin users)
Databases
I might propose that this be broken up to:
We just haven't built the postgres stuff into ceo yet, and since you're looking at re-writing it now seems like a better time than ever to integrate that.
Groups
Additionally,
If we're aiming for RESTful API, then I believe the correct order for this is:
Good idea. I propose a POST endpoint to
/api/members/pwreset
. When a new member is created, the backend should also take care of creating a password and expiring it.I guess here is attempt at this:
Members
Alternatively we could POST the the database we want to create so we will only need
Groups
Alternatively we could use PUT to update the position of a member in a club (and do other stuff)
Also we could move the renew to renew based on clubs/groups
I think I prefer using
/api/db
since we are performing an operation on a RDBMS and not on a Unix account.We only keep track of whether a member is in a group or not.
On a side note though, I think POST is more appropriate here, after looking at other APIs which insert members into groups.
There are only two types of renewals: for CSC members and for club reps. A rep can belong to multiple clubs, or even none at all. So I think that keeping the renewals in
/api/members
makes more sense.We should also support changing the forwarding email. It would probably fall under the PUT update endpoint.
API endpoints have now all been implemented 😄
n4chung referenced this issue2023-01-01 17:30:08 -05:00