includes messages of the first channel of the server
GET /api/servers - gets all servers that the current user is a member of
includes more specific data for the first server of the list (consult the points from GET /api/servers/:id)
POST /api/servers - create a new server
PATCH /api/servers/:id - edit a server
DELETE /api/server/:id - delete a server
POST /api/servers/:id/join - joins a given server as the current user (creates a server membership)
POST /api/servers/join - joins a given server as the current user (requires invite_token in posted data)
DELETE /api/servers/:id/leave - leaves a given server as the current user (deletes a server membership)
GET /api/servers/search?query=QUERY_STRING - searches all servers with a given query string (mini-bonus)
channels
GET /api/servers/:server_id/channels - gets all channels of a given server
GET /api/channels/:id - gets a specific channel, including messages (Bonus: limit to a time range)
POST /api/servers/:server_id/channels - create a new channel
PATCH /api/channels/:id - edit a channel
DELETE /api/channels/:id - delete a channel
messages
GET /api/channels/:channel_id/messages - gets all messages of a given channel
POST /api/channels/:channel_id/messages - post a message to the given channel
PATCH /api/messages/:id - edit a message
DELETE /api/messages/:id - delete a message
memberships
POST /api/servers/:server_id/memberships - joins a given server as the current user
DELETE /api/memberships/:id - leaves a given server as the current user
invitations (Bonus 2 only)
POST /api/invitations - creates an invitation (data includes a user and a server)
DELETE /api/invitations/:id - deletes an invitation
Notes
I crossed out a few redundant routes, can't think of a strong reason to implement them
GET /api/servers/:server_id/channels would fetch a subset of GET /api/servers/:id
GET /api/channels/:channel_id/messages would fetch a subset of GET /api/channels/:id
If implemented poorly, the initial load for a logged-in user would involve three chained fetches:
GET /api/servers -> GET /api/servers/:id -> GET /api/channels/:id/
The additional data sent in GET /api/servers/ should prevent that
Similarly, the additional data in GET /api/servers/:id should make switching servers more responsive
I moved the server_membership-releated routes to nested routes under servers, that way, there's no need for the front end to keep track of server_memberships and their ids