目录标题
膳逸:用户活动打卡相关开发文档
一、用户参与活动
要求:
1、不能参与已经参加的活动(因为在查询活动时,已经有了对能不能参与活动的check,前端只要把check为1的活动设置为能参与的活动,其他的为不能再参与的活动,那么这里就不用再进行无意义的判断)
2、活动参与人数要加一
开发思路
用户参与活动的功能主要包括以下几个步骤:
{
"userId": 4,
"activityId": 4
}
- 前端传递用户ID和活动ID到后端。
- 后端接收请求并将用户参与活动的信息存储到数据库中。
- 更新活动的参与人数。
<!-- 用户参与活动 -->
<insert id="participatingActivity" parameterType="Map">
INSERT INTO user_activity (user_id, activity_id)
VALUES (#{userId}, #{activityId});
</insert>
<!-- 参与完活动后活动参与人数要加一 -->
<update id="addParticipantsCount" parameterType="Map">
UPDATE activity
SET participants_count = participants_count + 1
WHERE id = #{activityId};
</update>
这样开发的好处
- 简化前端逻辑:前端只需负责将用户ID和活动ID传递到后端,不需要进行复杂的逻辑判断。
- 提高系统安全性:所有的逻辑判断和数据操作都在后端进行,避免了前端可能带来的安全隐患。
- 便于维护和扩展:将业务逻辑集中在后端,便于后续的维护和功能扩展。
POST 用户参与活动
POST /user/participatingActivity
前端返回用户id和活动id,参与活动
要求:1、不能参与已经参加的活动(因为在查询活动时,已经有了对能不能参与活动的check,前端只要把check为1的活动设置为能参与的活动,其他的为不能再参与的活动,那么这里就不用再进行无意义的判断)
2、活动参与人数要加一
Body 请求参数
{
"userId": 4,
"activityId": 4
}
请求参数
名称 | 位置 | 类型 | 必选 | 说明 |
---|---|---|---|---|
token | header | string | 否 | none |
body | body | object | 否 | none |
» userId | body | integer | 是 | none |
» activityId | body | integer | 是 | none |
返回示例
200 Response
{
"code": "string",
"msg": "string"
}
返回结果
状态码 | 状态码含义 | 说明 | 数据模型 |
---|---|---|---|
200 | OK | 成功 | Inline |
返回数据结构
状态码 200
名称 | 类型 | 必选 | 约束 | 中文名 | 说明 |
---|---|---|---|---|---|
» code | string | true | none | none | |
» msg | string | true | none | none |
二、用户活动打卡
开发思路
{
"userId": 5,
"activityId": 4,
"text": "活动打卡",
"time": "2024-5-24 02:03:22",
"images": "http://dummyimage.com/400x400"
}
用户活动打卡功能主要包括以下几个步骤:
- 用户在前端输入打卡信息,包括用户ID、活动ID、打卡文本、打卡时间和打卡图片。
- 前端将打卡信息发送到后端API。
- 后端接收打卡信息并存储到数据库中。
<!-- 用户活动打卡 -->
<insert id="checkInActivity" parameterType="Map">
INSERT INTO check_in_activity (user_id, activity_id, text, time, images, analysis)
VALUES (#{userId}, #{activityId}, #{text}, #{time}, #{images}, #{analysis});
</insert>
这样开发的好处
- 用户体验好:用户可以方便地在前端输入打卡信息,并立即得到反馈。
- 数据管理方便:所有打卡信息都存储在数据库中,便于后续的数据分析和管理。
- 系统扩展性强:将打卡功能独立出来,便于后续的功能扩展和维护。
POST 用户活动打卡
POST /user/checkInActivity
Body 请求参数
{
"userId": 5,
"activityId": 4,
"text": "活动打卡",
"time": "2024-5-24 02:03:22",
"images": "http://dummyimage.com/400x400"
}
请求参数
名称 | 位置 | 类型 | 必选 | 说明 |
---|---|---|---|---|
token | header | string | 否 | none |
body | body | object | 否 | none |
» userId | body | integer | 是 | none |
» activityId | body | integer | 是 | none |
» text | body | string | 是 | none |
» time | body | string | 是 | none |
» images | body | string | 是 | none |
返回示例
成功
{
"msg": "success",
"code": 200
}
返回结果
状态码 | 状态码含义 | 说明 | 数据模型 |
---|---|---|---|
200 | OK | 成功 | Inline |
返回数据结构
状态码 200
名称 | 类型 | 必选 | 约束 | 中文名 | 说明 |
---|---|---|---|---|---|
» msg | string | true | none | none | |
» code | integer | true | none | none |
三、修改用户活动打卡信息
开发思路
修改用户活动打卡信息的功能主要包括以下几个步骤:
-
用户在前端输入需要修改的打卡信息,包括打卡ID、打卡文本、打卡时间和打卡图片。
-
前端将修改后的打卡信息发送到后端API。
-
后端接收修改后的打卡信息并更新数据库中的记录。
-
后端部分:
- 接收前端传递的修改后的打卡信息。
- 更新数据库中的打卡记录。
<!-- 用户更新活动打卡 -->
<update id="updateCheckInActivityForm" parameterType="Map">
UPDATE check_in_activity
SET text = #{text},
time = #{time},
images = #{images}
WHERE id = #{checkInActivityId};
</update>
这样开发的好处
- 用户体验好:用户可以方便地在前端修改打卡信息,并立即得到反馈。
- 数据管理方便:所有修改后的打卡信息都存储在数据库中,便于后续的数据分析和管理。
- 系统扩展性强:将修改打卡功能独立出来,便于后续的功能扩展和维护。
POST 修改用户活动打卡信息
POST /user/updateCheckInActivity
用户修改用户活动打卡信息
Body 请求参数
{
"checkInActivityId": 1,
"text": "修改活动打卡",
"time": "1995-08-26 06:26:43",
"images": "http://dummyimage.com/200x200"
}
请求参数
名称 | 位置 | 类型 | 必选 | 说明 |
---|---|---|---|---|
token | header | string | 否 | none |
body | body | object | 否 | none |
» checkInActivityId | body | integer | 是 | none |
» text | body | string | 是 | none |
» time | body | string | 是 | none |
» images | body | string | 是 | none |
返回示例
成功
{
"msg": "success",
"code": 200
}
返回结果
状态码 | 状态码含义 | 说明 | 数据模型 |
---|---|---|---|
200 | OK | 成功 | Inline |
返回数据结构
状态码 200
名称 | 类型 | 必选 | 约束 | 中文名 | 说明 |
---|---|---|---|---|---|
» msg | string | true | none | none | |
» code | integer | true | none | none |
四、删除用户活动打卡信息
开发思路
{
"checkInActivityId": "2"
}
删除用户活动打卡信息的功能主要包括以下几个步骤:
-
用户在前端选择需要删除的打卡信息。
-
前端将打卡ID发送到后端API。
-
后端接收打卡ID并删除数据库中的记录。
-
后端部分:
- 接收前端传递的打卡ID。
- 删除数据库中的打卡记录。
<!-- 删除用户活动打卡信息-->
<delete id="deleteCheckInActivity" parameterType="Map">
DELETE FROM check_in_activity WHERE id = #{checkInActivityId};
</delete>
POST 删除用户活动打卡信息
POST /user/deleteCheckInActivity
删除用户活动打卡信息
Body 请求参数
{
"checkInActivityId": "2"
}
请求参数
名称 | 位置 | 类型 | 必选 | 说明 |
---|---|---|---|---|
token | header | string | 否 | none |
body | body | object | 否 | none |
» checkInActivityId | body | string | 是 | none |
返回示例
成功
{
"msg": "success",
"code": 200
}
返回结果
状态码 | 状态码含义 | 说明 | 数据模型 |
---|---|---|---|
200 | OK | 成功 | Inline |
返回数据结构
状态码 200
名称 | 类型 | 必选 | 约束 | 中文名 | 说明 |
---|---|---|---|---|---|
» code | integer | true | none | none | |
» msg | string | true | none | none |
五、查询活动总共打卡多少天
开发思路
查询用户在某个活动中总共打卡多少天的功能主要包括以下几个步骤:
-
前端传递用户ID和活动ID到后端。
-
后端接收请求并查询数据库,计算用户在该活动中打卡的总天数。
-
将查询结果返回给前端。
-
后端部分:
- 接收前端传递的用户ID和活动ID。
- 查询数据库,计算用户在该活动中打卡的总天数。
- 将查询结果返回给前端。
<!-- 查询活动总共打卡多少天 -->
<select id="countMyActivityCheckIn" parameterType="Map" resultType="java.lang.Long">
SELECT COUNT(DISTINCT DATE(time))
FROM check_in_activity
WHERE user_id = #{userId}
AND activity_id = #{activityId}
</select>
这样开发的好处
- 用户体验好:用户可以方便地在前端查询打卡天数,并立即得到反馈。
- 数据管理方便:所有打卡天数的计算都在数据库中进行,确保数据的准确性和一致性。
- 系统扩展性强:将查询功能独立出来,便于后续的功能扩展和维护。
POST 查询活动总共打卡多少天
POST /user/countMyActivityCheckIn
Body 请求参数
{
"userId": 5,
"activityId": 4
}
请求参数
名称 | 位置 | 类型 | 必选 | 说明 |
---|---|---|---|---|
token | header | string | 否 | none |
body | body | object | 否 | none |
» userId | body | integer | 是 | none |
» activityId | body | integer | 是 | none |
返回示例
200 Response
{
"code": "string",
"msg": "string"
}
返回结果
状态码 | 状态码含义 | 说明 | 数据模型 |
---|---|---|---|
200 | OK | 成功 | Inline |
返回数据结构
状态码 200
名称 | 类型 | 必选 | 约束 | 中文名 | 说明 |
---|---|---|---|---|---|
» code | string | true | none | none | |
» msg | string | true | none | none |
六、用户查询活动打卡信息
开发思路
查询用户在某个活动中的打卡信息的功能主要包括以下几个步骤:
- 前端传递用户ID和活动ID到后端。
- 后端接收请求并查询数据库,获取用户在该活动中的所有打卡信息。
- 将查询结果返回给前端。
开发过程
- 接收前端传递的用户ID和活动ID。
- 查询数据库,获取用户在该活动中的所有打卡信息。
- 将查询结果返回给前端。
<!-- 查询用户活动打卡信息 -->
<select id="searchCheckInActivity" parameterType="Map" resultType="java.util.HashMap">
SELECT * FROM check_in_activity
WHERE user_id = #{userId} AND activity_id = #{activityId}
</select>
Base URLs:
POST 用户查询活动打卡信息
POST /user/searchCheckInActivity
用户查询活动打卡信息
Body 请求参数
{
"userId": 5,
"activityId": 4
}
请求参数
名称 | 位置 | 类型 | 必选 | 说明 |
---|---|---|---|---|
token | header | string | 否 | none |
body | body | object | 否 | none |
» userId | body | integer | 是 | none |
» activityId | body | integer | 是 | none |
返回示例
成功
{
"msg": "success",
"result": [
{
"images": "http://dummyimage.com/400x400",
"user_id": 5,
"activity_id": 4,
"id": 1,
"text": "活动打卡",
"time": "2024-05-24T02:03:22"
},
{
"images": "http://dummyimage.com/400x400",
"user_id": 5,
"activity_id": 4,
"id": 2,
"text": "活动打卡2",
"time": "2024-05-24T08:03:22"
}
],
"code": 200
}
返回结果
状态码 | 状态码含义 | 说明 | 数据模型 |
---|---|---|---|
200 | OK | 成功 | Inline |
返回数据结构
状态码 200
名称 | 类型 | 必选 | 约束 | 中文名 | 说明 |
---|---|---|---|---|---|
» code | integer | true | none | none | |
» msg | string | true | none | none | |
» result | [object] | true | none | none | |
»» images | string | true | none | none | |
»» user_id | integer | true | none | none | |
»» activity_id | integer | true | none | none | |
»» id | integer | true | none | none | |
»» text | string | true | none | none | |
»» time | string | true | none | none |