Merging updated docs with updated get_<type>_channels uris

This commit is contained in:
shockrah 2020-05-25 13:48:23 -07:00
commit 1cb95cb59e
5 changed files with 69 additions and 51 deletions

View File

@ -1,10 +1,10 @@
# Preface # API
Voice connections are not yet authored as they are far from being implemented Voice connections are not yet authored as they are far from being implemented
# Auth Routes ## Auth Routes
## Logging in ### Logging in
Authenticated routes require a session key which this route provides, given a previously invited user's credentials Authenticated routes require a session key which this route provides, given a previously invited user's credentials
@ -25,7 +25,7 @@ Return:
Unix time stamp dictating when this key should be deleted server side. Though the server may delete the key later than this time-stamp the client can request a new token via `/auth/login` or `/auth/refresh`. Unix time stamp dictating when this key should be deleted server side. Though the server may delete the key later than this time-stamp the client can request a new token via `/auth/login` or `/auth/refresh`.
## Leaving an instance ### Leaving an instance
Parameters Parameters
- id - id
@ -37,7 +37,7 @@ Return:
On failure: An HTTP 400 Bad Request response; which parameter is wrong is not specified to avoid enumeration style attacks. On failure: An HTTP 400 Bad Request response; which parameter is wrong is not specified to avoid enumeration style attacks.
# Channels ## Channels
``` ```
/channels/list/voice /channels/list/voice
@ -52,7 +52,7 @@ Return:
Return: Return:
List of struct::Members in that given channel List of struct::Members in that given channel
# Messaging ## Messaging
``` ```
/message/recent/<channel> /message/recent/<channel>
@ -81,32 +81,3 @@ On paramter failure:
On server error: On server error:
HTTP 500 Internal Server Error HTTP 500 Internal Server Error
# Structures
Below are various structures that client builds can expect to receive.
```
Member {
name: string
id: u64
permissions: u64
}
Channel {
name: string
description: string
type: integer [1=Voice Channel, 2=Text Channel]
}
Message {
content: string
author: Member
date: Unix Timestamp<u64>
}
Badge {
name: string
permissions: u64
color: u32
}
```

13
docs/build-docs.sh Normal file
View File

@ -0,0 +1,13 @@
#!/bin/sh
# Builds all docs into a single easily searchable document
# Builds: HTML PDF TEXT versions of the documents.
chapters='api.md structures.md'
for chap in $chapters;do
cat $chap
done > freechat-docs.md
pandoc freechat-docs.md -o freechat-docs.pdf
pandoc freechat-docs.md -o freechat-docs.html

View File

@ -1,2 +0,0 @@
/auth/login
/auth/

50
docs/structures.md Normal file
View File

@ -0,0 +1,50 @@
# Structures
Below are various structures that client builds can expect to receive.
These are not representative of how instances internally store data but what a client can expect to receive from different API requests.
1. Member
```
Member {
name: string
id: u64
permissions: u64
badges: List<Badge>
}
```
2. Channel
```
Channel {
name: string
description: string
type: integer [1=Voice Channel, 2=Text Channel]
}
```
3. Message
While `Message` responses don't specify what channel they belong a channel
does have to be used to request these so it's up to the client to store these
in a way that makes sense.
```
Message {
author: Member
date: u64 -> [unix timestamp since epoch]
content: string
}
```
4. Badge
```
Badge {
name: string
permissions: u64
color: u32
}
```

View File

@ -1,14 +0,0 @@
# Server
- DB Model
- Data Persistence
- Permissions structure
- Channels(text)
# Client
- Frontend requesters for login/auth
- Auth management
- UI that doesn't succ