-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Labels
exec-onlyonly csss executives have the permission to do this, likely due to personal informationonly csss executives have the permission to do this, likely due to personal informationgood first issueGood for newcomersGood for newcomersnew featurean enhancementan enhancement
Description
Description
I'd like to store Event information somewhere and have our frontend be able to fetch it. I think there would need to be a new table created, as well as a new API endpoint.
The use-case for this is the frontend using it to build a calendar on the main site. The only thing the frontend needs for this are GET requests, but I may want to make something to make it easier to add events to the calendar.
If this can be done with Google Calendar or something, that's fine too, but show me a proof-of-concept so I don't have to research how to implement it.
Requirements
DB Table: Event
eid
(INTEGER): Event ID (primary key)name
(VARCHAR): Name of the eventstartTime
(DATETIME): Start time of the eventendTime
(DATETIME): End time of the event
Maybes
description
: Short description of the event.repeat
(VARCHAR/INTEGER): How often an event repeats- This one might be confusing, but either we use integers as agreed upon enum values (0 = never, 1 = bi-weekly, 2 = monthly, etc.) or we just write it down as a string. Events that happen yearly, but don't have a predictable date, like Frosh, Tech Fair, etc., should have a
0/"never"
for their value. This is so if we have a recurring event (like the bi-weekly events), we don't need to store each event; we just always receive these events and let the requester handle it however they want.
- This one might be confusing, but either we use integers as agreed upon enum values (0 = never, 1 = bi-weekly, 2 = monthly, etc.) or we just write it down as a string. Events that happen yearly, but don't have a predictable date, like Frosh, Tech Fair, etc., should have a
REST API Endpoints
- All requests should return
200
or404
unless stated otherwise. - Frontend will send data as
application/x-www-form-urlencoded
Note: Question marks indicate something that may not need to be added - GET
/event
: Get all events (might not be needed, but I'll put it here for completeness) - GET
/event/<year>
: Get events that start OR end in this year - GET
/event/<year>/<month>
: Get the events that start OR end in this month and year
- POST
/event
201
: successful creation
// POST body
{
"name": "string",
"startTime": "string/date",
"endTime": "string/date",
"description?": "string",
"repeat?": "string/number"
}
// POST response
{
"eid": "number",
"name": "string",
"startTime": "string/date",
"endTime": "string/date",
"description?": "string",
"repeat?": "string/number"
}
- PATCH
/event/<eid>
// PATCH body
{
"name": "string",
"startTime": "string/date",
"endTime": "string/date",
"description?": "string",
"repeat?": "string/number"
}
// PATCH response
{
"eid": "number",
"name": "string",
"startTime": "string/date",
"endTime": "string/date",
"description?": "string",
"repeat?": "string/number"
}
- DELETE
/event/<eid>
404
: If nothing was deleted
// DELETE body
{
"eid": "number"
}
// DELETE response
{
"result": "success | failure",
"eid": "number"
}
Metadata
Metadata
Assignees
Labels
exec-onlyonly csss executives have the permission to do this, likely due to personal informationonly csss executives have the permission to do this, likely due to personal informationgood first issueGood for newcomersGood for newcomersnew featurean enhancementan enhancement