在REST中创建实体关系：我可以通过发布到子ID来创建父关系吗？

我们目前正在设计一种REST API，以访问经典客户数据。API中的元素之一是用户的资产。资产在给定服务下添加。后端API仅会在给定服务下向用户添加资产。因此，没有用户-资产关系，而是用户-[服务]-资产关系。

我们的URI如下所示：

/users/{id}/assets/{id}/services/{id}

使用API​​会知道资产ID和服务ID，以创建新条目。我们正在努力的是建立这种关系。

一种简单的方法是将整个关系发布到 /users/{id}/assets/

POST /users/{id}/assets    
{asset:${id}, service:{id}, attribute1:"{var}", attribute2:"{var}"}

但是我们实际上并不是在创建URI可能表明的资产，而是资产-服务关系。

作为替代方案，我们正在考虑将POST'ing到解决该关系的URI，如下所示：

POST /users/{id}/assets/{id}/service/{id}
{attribute1:"{var}", attribute2:"{var}"}

但是在这种情况下，资源路径/users/{id}/assets/{id}在POST之前将不存在，并且将被创建为副作用。

是否将POST发送到尚不存在的资源路径？

谢谢你的想法

杰拉德。

听起来您似乎在建议，每当用户首次发布到不存在的关系时，您都将其创建为发布的一部分。

如果您要问这种按访问创建的模式是否是有效的，可接受的开发模式，答案是肯定的-它既有效，又是一种相当常见的模式。

这里有很多要点：第一：创建新资源时不应放置该ID，因为该ID已经存在，或者是系统使用特定技术生成该ID且您正在强迫它使用您的ID，对于提议必须由系统创建ID，以在创建资源的情况下必须设置位置标头属性，以获取具有所生成ID的反馈。

第二：您的JSON不正确，您必须将服务作为资产对象中的另一个对象来处理，就像在资源URI服务中一样，您也必须将它作为数组来处理。

POST /users/{id}/assets    
{asset:${id}, service:{id}, attribute1:"{var}", attribute2:"{var}"}

必须：

POST /users/{id}/assets    
{services:[{ attribute1:"var", attribute2:"var"}]}

如果您要使用这种方式

第三：我不喜欢使用这种方式进行设计建议，如果这种情况失败了，您怎么知道在创建资产或服务时失败了，

这是另一种思路：

POST /relationships
{ relationship:${id}, asset:{id}, service:{id}, user:{id}, data:"some data" }

这样，您将关系定义为资产，服务和用户之间的三向链接，而不意味着任何层次关系

然后，您可以通过以下方式检索特定的关系：

GET /relationships?id="2144321"

或通过以下方式搜索关系的子集：

GET /relationships?user="43434"

要么

GET /relationships?asset="12433"

最初的方法没有错，但是这种方法可以为您提供更大的灵活性，使其适用于谁。