在发言人在不同会话中讲话的事件管理系统的背景下。我的实体是演讲者和会议
假设端点是
1)POST /speakers
(仅插入发言人的详细信息)
2)POST /speakers
(插入演讲者的详细信息+他正在谈论的会话的ID)
第2点需要在连接表中执行额外的插入。
如何在同一端点中指定两种操作。
答案 0 :(得分:0)
可以代表一位发言者,包括他所讲的会议。例如:
{
"id": 1234,
"firstname": "Joe",
"lastname": "Doe",
"sessions": []
}
此表示表示发言人未在任何会话上发言。 sessions
是一个空数组。做
POST /speakers
Content-Type: application/json
如上图所示,使用JSON主体将创建扬声器。
如果客户事先知道发言人会说话的所有会话,那么JSON可能如下所示:
{
"id": 1234,
"firstname": "Joe",
"lastname": "Doe",
"sessions": [
{
"id": 12,
"link": "/session/12"
},
{
"id": 34,
"link"; "/session/34"
}
]
}
对于发言者正在发言的每个会话,包括仅包含会话的id
和link
的短对象。这应该足以让服务器知道如何链接数据库中的发言者和会话。
现在让我们考虑这样一种情况,即发言人将要发言的会议是不是客户提前知道的。客户端将使用上面的第一个JSON表示创建说话者,包括空的sessions
数组。之后,当发言人所说的所有会话都为客户所知时,他会提出PATCH
请求:
PATCH /speakers/1234
Content-Type: application/json
{
"sessions": [
{
"id": 12,
"link": "/session/12"
},
{
"id": 34,
"link"; "/session/34"
}
]
}
请注意,现在我们只发送sessions
。扬声器的所有其他属性应保留在服务器上。
如果客户想要一个接一个地向发言人添加会话,他可以为每个会话执行此操作:
POST /speakers/1234/sessions
Content-Type: application/json
{
"id": 43,
"link": "/sessions/43"
}
这意味着:"将会话43添加到发言者1234和#34;的会话列表中。此处/speakers/1234/sessions
是/speaker/1234
的子资源。添加它是有道理的(当然服务器必须检查重复)。
请注意POST
对创建新资源(发言人)的不同用法,添加到子资源(会话列表)。另请注意,仅更改资源(发言人)的部分使用PATCH
。
修改强>
如果客户端想要发送资源的完整表示,则通常使用HTTP动词PUT
。将会话列表添加到现有发言人时,我们会在发言人上使用PATCH
,因为在他身上使用PUT
会要求客户端发送发言人的完整代表。在这个用例中,客户端不想这样做,他想设置会话列表。
另一种方法可能是
PUT /speakers/1234/sessions
Content-Type: application/json
[
{
"id": 12,
"link": "/session/12"
},
{
"id": 34,
"link"; "/session/34"
}
]
在子资源 sessions
上使用完整的会话列表。请注意区别:此处客户端正在发送演讲者会话列表的完整表示。这里PUT
表示:"用我提供的内容覆盖此发言人的完整会话列表"。
使用/speakers?eventId=1
获取偶数1
的发言人名单是一种很好的做法。这里,客户端请求集合资源/speakers
的过滤子集。使用查询参数来表达过滤条件非常常见。
关于这种知识的良好资源,我的一般建议是始终考虑资源。您的API提供了哪些资源?不同类型的资源如何相关?它们是否可以彼此相邻(扬声器可以在没有会话的情况下存在,会话可以在没有发言者的情况下存在),或者是复合物(酒店房间只能存在于酒店内)。通常这种问题会有所帮助。但是在REST中没有硬性规则或标准"如何构建必须的URL。我认为在API中保持一致非常重要。