我有包装作为资源。一个包可以有父包,依此类推。根目录包是层次结构的顶层。现在,用例是:
鉴于任何软件包(不一定是根软件包)的packageId,我想检索位于其顶层结构中的根软件包的详细信息。
我对2个网址感到困惑:(或其他更好的网址)
/rest/v1/packageDetails/rootPackage/{packageId}
或
/rest/v1/packageDetails/{packageId}/rootPackage
最合适的休息终点网址应该是什么?
答案 0 :(得分:1)
选项2 。为了演示推理,我将使用另一个示例。
让我们说您有一个REST API端点:
/rest/v1/users/{userId}
如果您想创建一个额外的端点来检索数据的子集,例如attributes
,则可以这样构造:
/rest/v1/users/{userId}/attributes
另一个为用户检索特定属性的用例可能看起来像:
/rest/v1/users/{userId}/attributes/{attributeId}
要注意的重要一点是,属性属于。该属性是特定用户拥有的一或多个数据位。
在您的情况下,程序包具有一个rootPackage,因此您可以将rootPackage建模为属于特定程序包。
答案 1 :(得分:1)
REST是一种建筑风格,而不是用于设计URI的食谱。现在,如果您要遵守 REST标准,则应该考虑超媒体。
假设存在用于为您的资源设计URI的REST标准是一个误解: REST不执行或不建议任何URI设计。
URI语法在RFC 3986中定义,这是在设计URI时应考虑的文档。通常,该路径以 hierarchical 形式组织(各段之间用/
分隔),并且可以在查询组件中(从?
开始包含非分层数据)。
如果我正确理解了您的问题,则只需使用/rest/v1/packageDetails/{packageId}
来识别软件包。
然后使用超媒体链接到其他软件包。您可以在标题或响应有效负载中提供links。例如,在JSON有效负载中,您可以:
{
"id": "foo",
"content": {...},
"_links":{
"self":{
"href":"http://localhost:8080/rest/v1/packageDetails/foo"
},
"root":{
"href":"http://localhost:8080/rest/v1/packageDetails/bar"
},
"parent":{
"href":"http://localhost:8080/rest/v1/packageDetails/biz"
},
"children":{
"href":"http://localhost:8080/rest/v1/packageDetails/foo/children"
}
}
}
答案 2 :(得分:0)
您的选择都不完全正确。为什么:
对于选项一,/rest/v1/packageDetails/rootPackage/{packageId}
应该是将返回内容的URI。但是此URI上的ID将是将要返回的资源的子ID。
出于类似的原因,选项2的URI /rest/v1/packageDetails/{packageId}/rootPackage
会假设rootPackage
是/rest/v1/packageDetails/{packageId}
的子资源,这在我们查找a时是荒谬的。父项在其子项下。
我个人会添加并推荐的第三个选项是简单地使用客户端定义级别的搜索(在包层次结构中):
/rest/v1/packageDetails/?childId=packageId&level=0
这将返回packageId
所在树中的顶级包。我以level=0
为例,说明了软件包在其自身层次结构中的位置。
对资源有很好的了解之后,您可以选择一个更合适的名称或类型,但是我相信这是一个更好的选择。