JavanTang commented 2 years ago

更新时间: 2022-10-25

1. 更新用户操作

MODE UPDATE Input

一次性给全部数据: 影响速度
{
    "room_id": "AAA",  # 房间号
    "room_member_setting": [{  # 房间成员设置
        "default_color": "#000000",
        "name": "",
        "type": ""
    }],
    "room_content": [ # 房间具体内容

    ]
}

2. 获取当前房间所有信息

MODE `GET` Input	名称	说明	默认
room_id	房间号	1234123kjflkhqnekt

output

{
    "room_id": "AAA",  # 房间号
    "room_member_setting": [{  # 房间成员设置
        "default_color": "#000000",
        "name": "",
        "type": ""
    }],
    "room_content": [ # 房间具体内容

    ]
}

3. 上传图片信息

MODE PUT Input base64 Output

{
    "img_id":"asdflkjflfasdf"
}

4. 获取图片信息

MODE GET Input images?q=tbn:ANd9GcRhMwruSVd3amTYdRfv9STKaZ48MDaB4LO2DQLx74GRfQ&s

JavanTang commented 2 years ago

@uiuing 这是初步设计API版本，抽时间讨论后再调整

uiuing commented 2 years ago

@uiuing 这是初步设计API版本，抽时间讨论后再调整

收到🫡

JavanTang commented 2 years ago

更新时间: 2022-10-27

1. 长连接(WebSocket操作)

用户行为有:新建房间, 进入房间, 新建形状, 更新形状, 删除形状, 更新用户设置,执行权限行为

对上面行为,应该在每次json数据中带上一个type类型,这样更加方便后台处理这些行为	行为	type
新建房间	create
进入房间	join
新建形状	shape_new
更新形状	shape_update
删除形状	shape_delete
更新用户设置	user_update
执行权限行为	gm_update

1.1 新建房间

Input

一次性给全部数据: 影响速度
{
    "type":"create"
}

Output

{
    "room_member_setting": [{  # 房间成员设置
        "default_color": "#000000",
        "name": "",
        "type": ""
    }],
    "room_content": [ # 房间具体内容

    ]
}

1.2 进入房间

Input

{
    "type":"join"
}

output 新用户

{
    "room_member_setting": [{  # 房间成员设置
        "default_color": "#000000",
        "name": "",
        "type": ""
    }],
    "room_content": [ # 房间具体内容

    ]
}

其他房间成员

{
    "type":"join",
    "res":{
        "room_member_setting": [{  # 房间成员设置
            "default_color": "#000000",
            "name": "",
            "type": ""
        }],
        "room_content": [ # 房间具体内容

        ]
    }
}

1.3 新建形状

Input

{
    "type":"shape_new",
    "content":{
        %%具体操作内容%%
    }
}

Output

{
    "type":"shape_new",
    "content":{
        %%具体操作内容%%

        "shape_id": 1235lk1j23  %%这个是这个形状的唯一编码%%
    }
}

1.3 更新形状

Input

{
    "type":"shape_update",
    "content":{
        "shape_id": 1235lk1j23
        %%具体操作内容%%
    }
}

Output

{
    "type":"shape_update",
    "content":{
        "shape_id": 1235lk1j23
        %%具体操作内容%%
    }
}

1.4 删除形状

Input

{
    "type":"shape_delete",
    "content":{
        "shape_id": 1235lk1j23
    }
}

Output

{
    "type":"shape_delete",
    "content":{
        "shape_id": 1235lk1j23
    }
}

2. 短连接

2.1 上传图片信息

MODE PUT Input base64 Output

{
    "img_id":"asdflkjflfasdf"
}

2.2 获取图片信息

MODE GET Input images?q=tbn:ANd9GcRhMwruSVd3amTYdRfv9STKaZ48MDaB4LO2DQLx74GRfQ&s

JavanTang commented 2 years ago

@uiuing 上面是今天思考的API，有空看看，也不一定是最终版，只是每天有点新心得（狗头~）

uiuing commented 2 years ago

@uiuing 上面是今天思考的API，有空看看，也不一定是最终版，只是每天有点新心得（狗头~）

好的嘞，收到🫡 ，预计底层API最晚29号完成

uiuing commented 2 years ago

更新时间: 2022-10-27

1. 长连接(WebSocket操作)

用户行为有:新建房间, 进入房间, 新建形状, 更新形状, 删除形状, 更新用户设置,执行权限行为

对上面行为,应该在每次json数据中带上一个type类型,这样更加方便后台处理这些行为

| 行为 | type |

| ------------ | ------------ |

| 新建房间 | create |

| 进入房间 | join |

| 新建形状 | shape_new |

| 更新形状 | shape_update |

| 删除形状 | shape_delete |

| 更新用户设置 | user_update |

| 执行权限行为 | gm_update |

1.1 新建房间

Input
一次性给全部数据: 影响速度

{

  "type":"create"

}
Output
{

  "room_member_setting": [{  # 房间成员设置

      "default_color": "#000000",

      "name": "",

      "type": ""

  }],

  "room_content": [ # 房间具体内容

  ]

}
1.2 进入房间

Input
{

  "type":"join"

}
output

新用户
{

  "room_member_setting": [{  # 房间成员设置

      "default_color": "#000000",

      "name": "",

      "type": ""

  }],

  "room_content": [ # 房间具体内容

  ]

}
其他房间成员
{

  "type":"join",

  "res":{

      "room_member_setting": [{  # 房间成员设置

          "default_color": "#000000",

          "name": "",

          "type": ""

      }],

      "room_content": [ # 房间具体内容

      ]

  }

}
1.3 新建形状

Input
{

  "type":"shape_new",

  "content":{

      %%具体操作内容%%

  }

}
Output
{

  "type":"shape_new",

  "content":{

      %%具体操作内容%%

      "shape_id": 1235lk1j23  %%这个是这个形状的唯一编码%%

  }

}
1.3 更新形状

Input
{

  "type":"shape_update",

  "content":{

      "shape_id": 1235lk1j23

      %%具体操作内容%%

  }

}
Output
{

  "type":"shape_update",

  "content":{

      "shape_id": 1235lk1j23

      %%具体操作内容%%

  }

}
1.4 删除形状

Input
{

  "type":"shape_delete",

  "content":{

      "shape_id": 1235lk1j23

  }

}
Output
{

  "type":"shape_delete",

  "content":{

      "shape_id": 1235lk1j23

  }

}
2. 短连接

2.1 上传图片信息

MODE

PUT

Input

base64

Output
{

  "img_id":"asdflkjflfasdf"

}
2.2 获取图片信息

MODE

GET

Input

images?q=tbn:ANd9GcRhMwruSVd3amTYdRfv9STKaZ48MDaB4LO2DQLx74GRfQ&s

对于内容的增删改，就采用这个API格式怎么样，如果可以我就开始写数据更新的监听/设置了，后台转发即可

uiuing commented 2 years ago

关于数据同步流程，只是初步设想，后期根据需求修改未命名文件(8)

JavanTang commented 2 years ago

更新时间: 2022-10-31

1. 长连接(WebSocket操作)

用户行为有:新建房间, 进入房间, 新建形状, 更新形状, 删除形状, 更新用户设置,执行权限行为

对上面行为,应该在每次json数据中带上一个type类型,这样更加方便后台处理这些行为	行为	type
新建房间	create_room	完成
进入房间	join_room	完成
新建形状	new_shape	完成
更新形状	update_shape	完成
删除形状	delete_shape	完成
更新用户设置	user_update	未完成
执行权限行为	gm_update	没完成

1.1 新建房间

Input


{
    "type":"create_room",        %%创建房间%%
    "room_name":"默认",      %%用户名称%%
    "room_type":0,          %%0为公开, 1 为私人%%
    "room_owner_avatar":0   %%默认头像%%
}

Output

{
    "status": 200,
    "msg": "创建房间成功",
    "data": {
        "room_id": "fb871334-56c2-11ed-b8f2-e526f1815a4c",
        "room_name": "默认",
        "room_type": 0,
        "room_status": 0,
        "room_members": [
            "127.0.0.1"
        ],
        "room_member_setting": {
            "127.0.0.1": {
                "default_color": "#000000",
                "name": "1",
                "type": ""
            }
        },
        "room_content": [
        ]
    }
}

1.2 进入房间

Input

{
    "room_id":"fb871334-56c2-11ed-b8f2-e526f1815a4c",
    "type":"join_room",
    "room_member_setting": {  # 房间成员设置
        "default_color": "#000000",
        "name": "",
        "type": "",
        "room_owner_avatar":0
    }
}

output 新用户

{
    "room_member_setting": [{  # 房间成员设置
        "default_color": "#000000",
        "name": "",
        "type": ""
    }],
    "room_content": [ # 房间具体内容

    ]
}

其他房间成员

{
    "type":"join",
    "res":{
        "room_member_setting": [{  # 房间成员设置
            "default_color": "#000000",
            "name": "",
            "type": ""
        }],
        "room_content": [ # 房间具体内容

        ]
    }
}

1.3 新建形状

Input

{
    "type":"new_shape",
    "content":{
        "shape_id":"123"
    }
}

Output

{
    "type":"new_shape",
    "content":{
        "shape_id": "123"  %%这个是这个形状的唯一编码%%
    }
}

1.3 更新形状

Input

{
    "type":"update_shape",
    "content":{
        "shape_id": 1235lk1j23
    }
}

Output

{
    "type":"update_shape",
    "content":{
        "shape_id": 1235lk1j23
    }
}

1.4 删除形状

(用户操作回滚,后台需要及时响应) Input

{
    "type":"delete_shape",
    "content":{
        "shape_id": 1235lk1j23
    }
}

Output

{
    "type":"delete_shape",
    "content":{
        "shape_id": 1235lk1j23
    }
}

2. 短连接（未开始）

2.1 上传图片信息

MODE PUT Input base64 Output

{
    "img_id":"asdflkjflfasdf"
}

2.2 获取图片信息

MODE GET Input images?q=tbn:ANd9GcRhMwruSVd3amTYdRfv9STKaZ48MDaB4LO2DQLx74GRfQ&s

uiuing commented 2 years ago

需要同步的数据格式

{
  "nodes":[
        {
              "id":"jskdjbuiew",
              ......
        },
        ......
   ],
  "state":{
       "readonly":true,
       .....
   }
}

传递对象

对象有两种大类，一个是更改 state ，一个是更改 nodes

更改 state 所有 type 的类型：update-state
更改 nodes 所有 type 的类型：update、delete-all、cover-all、add、delete

`update-state` 更新 state

通过 object[key] = nowObject[key] 覆盖

{
      "type": "update-state",
      "state":{
              "更新的key":"更新的数据"
              .......
      }
}

`update` 更新 nodes

找到id后，通过 object[key] = nowObject[key] 覆盖

{
      "type": "update",
      "nodes":[
             {
                  "id":"aaaaaa"
                  "更新的key":"更新的数据"
                   .......
              }
             {
                  "id":"bbbb"
                  "更新的key":"更新的数据"
                   .......
              }
      ]
}

`delete-all` 删除全部 nodes

{
      "type": "delete-all"
}

`cover-all` 覆盖全部 nodes

直接覆盖在代码的执行逻辑上....... 貌似这种情况不会发生，保留是为了避免错误

{
      "type": "cover-all",
      "nodes":[ ..... ]
}

`add` 新增 node

可以新增多个，所以nodes对象是个数组，追加到末尾，尽量保留原顺序

{
      "type": "add",
      "nodes":[
             {
                     .......
              },
             {
                     .......
              }  
      ]
}

`delete` 删除 node

可以删除多个，所以nodes对象是个数组，根据id删除，尽量保留原顺序

{
      "type": "delete",
      "nodes":[
             {
                  "id":"aaa"
              },
             {
                  "id":"bbb"
             }  
      ]
}

@JavanTang

uiuing commented 2 years ago

还需要：进入房间需要昵称和颜色和房间id，相同昵称去除

uiuing commented 2 years ago

creat API 需求文档

一、创建会议

每个容器一个id，可以在此容器基础上创建会议，所有数据前端提供。

1.1 输入

{
  "type": "create_meeting",    // 传输数据类型
  "whiteboard":{
    "id":"xxxxxxxxxxx",       // 容器唯一识别
    "name": "未命名文件1",     // 容器名称 
    "nodes":[],              // 初始容器数据
    "readonly":false         // 这里是全局的是否只读状态
  },
  "user":{
    "id":"xxxxxxxxxxx",  // 用户唯一识别  
    "name":"xxxx",      // 用户昵称
    "color":"xxx",     // 用户默认颜色
  }
}

1.2 响应

{
  "status": 200,
  "msg": "创建房间成功",
}

1.3 数据缓存

创建会议之后将数据上传，后台提供 redis 缓存，（在作者断开之后也不清除）（保存初始数据和作者id）

类似这样

key: creat-xxxxxxxx (creat-容器id)
value: {
  "author_id": "xxxxx",
  "whiteboard":{
    "name": "未命名文件1",     // 容器名称 
    "nodes":[],              // 初始容器数据
    "readonly":false         // 这里是全局的是否只读状态
  },
}

二、检查会议

先要有接口判断会议是否存在，即判断缓存是否有id，并且获取权限

2.1 输入

{
  "type": "check_meeting",
  "whiteboard":{
    "id":"xxxxxxxxxxx",      // 容器唯一识别
  },
}

2.2 响应

2.2.1 缓存中已存在该容器（已创建）

{
  "status":200
  "whiteboard":{
    "name": "未命名文件1",     // 容器名称 
    "readonly":true         // 这里是全局的是否只读状态
  },
}

2.2.2 缓存中不存在该容器（未创建）

{
  "status":404
}

三、进入会议

容器是否只读由章节：“二、检查会议” 获取，前端判断。

3.1 输入

3.1.1 容器只读情况下输入

{
  "type": "join_meeting",
  "whiteboard":{
    "id":"xxxxxxxxxxx",      // 容器唯一识别
  },
}

3.1.1 容器非只读情况下输入

{
  "type": "join_meeting",
  "whiteboard":{
    "id":"xxxxxxxxxxx",      // 容器唯一识别
  },
  "user":{      
    "id":"xxxxxxxxxxx",  // 用户唯一识别
    "name":"aaa",       // 用户昵称 （加入的时候会判断，是否已经存在该用户昵称，存在则反馈）   
    "color":"xxx",     // 用户默认颜色
  }
}

3.2 响应

这里和创建会议时缓存里的的作者id对比

3.2.1 容器只读情况下

a. 加入的是作者，则响应

如果加入的是作者，则为：

{
  "whiteboard":{
    "name": "未命名文件1",     // 容器名称 
    "nodes":[],              // 初始容器数据
    "readonly":true        // 这里是全局的是否只读状态
  },
  "user_rights":"author"  // 用户类型
}

b. 加入的是贡献者，则响应

加入的不是作者，则是：

{
  "whiteboard":{
    "name": "未命名文件1",       // 容器名称 
    "nodes":[],               // 初始容器数据
    "readonly":true         // 这里是全局的是否只读状态
  },
  "user_rights":"contributor"   // 用户类型
}

c. 转发给其他成员

无

3.2.2 容器非只读情况下

a. 加入的是作者，则响应

如果加入的是作者，则为：

{
  "whiteboard":{
    "name": "未命名文件1",         // 容器名称 
    "nodes":[],                 // 初始容器数据
    "readonly":false           // 这里是全局的是否只读状态
  },
  "user_rights":"author",    // 用户类型
  "cooperation_users": [    // 已在线协作用户数据
    {  
      "name": "aaa",
      "color": "xxx",
      "rights": "contributor"
    }
    .....
  ],
}

b. 加入的是贡献者，则响应

加入的不是作者，则是：

{
  "whiteboard":{
    "name": "未命名文件1",            // 容器名称 
    "nodes":[],                    // 初始容器数据
    "readonly":false              // 这里是全局的是否只读状态
  },
  "user_rights":"contributor",  // 用户类型
  "cooperation_users": [       // 已在线协作用户数据
    {  
      "name": "aaa",
      "color": "xxx",
      "rights": "contributor"
    }
    .....
  ],
}

c. 转发给其他成员

{
  "type": "join_meeting",
  "join_user":{      
    "name":"aaa",       // 用户昵称 （加入的时候会判断，是否已经存在该用户昵称，存在则反馈）   
    "color":"xxx",     // 用户默认颜色
  }
}

四、退出会议

4.1 输入

{
  "type": "quit_meeting",
  "user":{
    "name":"xxxxx"   // 用户昵称 
  }
}

4.2 其他成员响应

{
  "type": "quit_meeting",
  "user":{
    "name":"xxxxx"   // 用户昵称 
  }
}

五、关闭会议

只有作者可以关闭，同样判断id是否和缓存里的id是否相同，关闭之后则删除缓存

5.1 输入

{
  "type": "close_meeting",
  "user":{
    "id":"xxxxxxxxxxx",  // 用户唯一识别
  }
}

六、更改会议状态

只有作者有权限，修改之后，redis中的缓存数据也会修改

6.1 输入

{
  "type": "change_meeting",    // 传输数据类型
  "whiteboard":{
    "name": "修改文件1",      //  容器名称                 // 这个可以修改
    "readonly":true         // 这里是全局的是否只读状态   // 这个可以修改
  }
}

6.2 给作者的响应

{
  "status": 200,
  "msg": "成功",
}

6.3 其他成员响应

{
  "type": "change_meeting",    // 传输数据类型
  "whiteboard":{
    "name": "修改文件1",      //  容器名称
    "readonly":true         // 这里是全局的是否只读状态
  },
}

七、更改会议容器数据（同步）

readonly 为 true 的时候，只有作者可以修改，当然前端也不会发送数据。

后端对redis中的缓存同样进行更新，之后再转发给其它人

"whiteboard":{
    "name": "未命名文件1",
    "nodes":[],              // 👈这里
    "readonly":false
  },

7.1 `update` 更新 nodes

找到id后，通过 node[key] = newNode[key] 覆盖

输入

{
  "type": "nodes-update",
  "nodes":[
    {
      "id":"aaaaaa"
      "更新的key":"更新的数据"
        .......
    },
    {
      "id":"bbbb"
      "更新的key":"更新的数据"
        .......
    }
  ]
}

输出

{
  "type": "nodes-update",
  "nodes":[
    {
      "id":"aaaaaa"
      "更新的key":"更新的数据"
        .......
    },
    {
      "id":"bbbb"
      "更新的key":"更新的数据"
        .......
    }
  ]
}

7.2 `add` 新增 node

可以新增多个，所以nodes对象是个数组，追加到末尾，尽量保留原顺序

输入

{
  "type": "add",
  "nodes":[
    {
      .......
    },
    {
      .......
    }  
  ]
}

输出

{
  "type": "add",
  "nodes":[
    {
      .......
    },
    {
      .......
    }  
  ]
}

7.3 `delete` 删除 node

可以删除多个，所以nodes对象是个数组，根据id删除，尽量保留原顺序

输入

{
  "type": "delete",
  "nodes":[
    {
      "id":"aaa"
      },
    {
      "id":"bbb"
    }  
  ]
}

输出

{
  "type": "delete",
  "nodes":[
    {
      "id":"aaa"
      },
    {
      "id":"bbb"
    }  
  ]
}

7.4 `delete-all` 删除全部 nodes

输入

{
  "type": "nodes-delete-all"
}

7.5 `cover-all` 覆盖全部 nodes

直接覆盖在代码的执行逻辑上....... 貌似这种情况不会发生，保留是为了避免错误

输入

{
  "type": "cover-all",
  "nodes":[ ..... ]
}

7.6 鼠标位置同步

鼠标按下去的时候传输位置并显示

TODO

uiuing / creat

API Design #7

1. 更新用户操作

2. 获取当前房间所有信息

3. 上传图片信息

4. 获取图片信息

1. 长连接(WebSocket操作)

1.1 新建房间

1.2 进入房间

1.3 新建形状

1.3 更新形状

1.4 删除形状

2. 短连接

2.1 上传图片信息

2.2 获取图片信息

1. 长连接(WebSocket操作)

1.1 新建房间

1.2 进入房间

1.3 新建形状

1.3 更新形状

1.4 删除形状

2. 短连接

2.1 上传图片信息

2.2 获取图片信息

1. 长连接(WebSocket操作)

1.1 新建房间

1.2 进入房间

1.3 新建形状

1.3 更新形状

1.4 删除形状

2. 短连接 （未开始）

2.1 上传图片信息

2.2 获取图片信息

需要同步的数据格式

传递对象

update-state 更新 state

update 更新 nodes

delete-all 删除全部 nodes

cover-all 覆盖全部 nodes

add 新增 node

delete 删除 node

目录

creat API 需求文档

一、创建会议

1.1 输入

1.2 响应

1.3 数据缓存

二、 检查会议

2.1 输入

2.2 响应

2.2.1 缓存中已存在该容器（已创建）

2.2.2 缓存中不存在该容器 （未创建）

三、进入会议

3.1 输入

3.1.1 容器只读情况下输入

3.1.1 容器非只读情况下输入

3.2 响应

3.2.1 容器只读情况下

3.2.2 容器非只读情况下

四、退出会议

4.1 输入

4.2 其他成员响应

五、关闭会议

5.1 输入

六、更改会议状态

6.1 输入

6.2 给作者的响应

6.3 其他成员响应

七、更改会议容器数据（同步）

7.1 update 更新 nodes

7.2 add 新增 node

7.3 delete 删除 node

7.4 delete-all 删除全部 nodes

7.5 cover-all 覆盖全部 nodes

7.6 鼠标位置同步

2. 短连接（未开始）

`update-state` 更新 state

`update` 更新 nodes

`delete-all` 删除全部 nodes

`cover-all` 覆盖全部 nodes

`add` 新增 node

`delete` 删除 node

二、检查会议

2.2.2 缓存中不存在该容器（未创建）

7.1 `update` 更新 nodes

7.2 `add` 新增 node

7.3 `delete` 删除 node

7.4 `delete-all` 删除全部 nodes

7.5 `cover-all` 覆盖全部 nodes