Alert系统的REST API设计

Question

我是REST API设计的新手，我想知道如何设计一个如下定义的问题。我还概述了我目前的想法，但显然我发现它有很多问题

• Cluster有Alerts
• Alerts是Alert_Type
的实例
• 可以将Alert_Type分配给Cluster(s)。在这种情况下Cluster 已注册Alerts个Alert_Type
• 还可以将Alert_Type分配给无Cluster
• 当Alert中出现Alert_Type实例Cluster时，会执行一些操作 当且仅当Alert_Type已在Cluster注册并且Alert_Type存在
时才会发生

出于这个问题的目的，我关注Alert_Type对象和Cluster对象

的REST API设计和路由

这些是我可以在Cluster对象上执行的REST操作的子集：

POST ：创建一个新的Cluster对象。在对象中，名为registered_alerts的字段可以包含为此Alert_Type

注册的Cluster个对象

删除：删除现有的Cluster对象

获取（在/ alert_types上）：将返回使用此Alert_Type

注册的Cluster个对象的列表

这些是我可以在Alert_Type对象上执行的REST操作的子集：

POST ：创建一个新的Alert_Type对象。

删除：删除现有的Alert_Type对象

获取：获取现有的Alert_Type对象

现在我的问题：

1. 显然我需要绑定Cluster和Alert_Type个对象 - 我 知道复制Alert_Type对象的不好设计 Cluster个对象。所以也许我应该为每个人生成一个id Alert_Type对象并要求Cluster POST发送一个id 代替？然后在Cluster对象
中维护一个id列表
2. 如果Cluster POST有一堆Alert_Type ID，那就是 有效，有些不是，我该如何处理？
3. 必须在服务器上生成Alert_Type的唯一ID， 并在Alert_Type的POST回复中返回 - 什么是以兼容REST的方式执行此操作的正确方法？
4. 您认为甚至需要保留Cluster ID Alert_Type个对象？我能看到需要的唯一原因 这是在删除Alert_Type时 - 然后应该删除 更新正在关注此Cluster
的Alert_Type个对象

Answer 1

我试着给你一个回应：

1. 是的，您应该使用Cluster对象中的id。
2. 您必须返回错误，不要保存任何内容。
3. 我应该在POST响应中返回创建的Alert_Type的id（例如，json {＆＃39; id＆＃39;：＆＃39; theId＆＃39;}）。
4. 这取决于数据库实现：如果你只需要恢复群集连接到删除Alert_type我建议你不要保持反向连接，因为如果你这样做，你还有一个要管理的字段。

希望我可以帮忙。