【问题标题】:Using wildcards (*) in REST API resource name在 REST API 资源名称中使用通配符 (*)
【发布时间】:2018-02-24 07:20:08
【问题描述】:

在 REST API 中使用 * 作为资源 ID 是否明智?我想用它来搜索。我正在使用 RESTEasy 开发我的网络服务。

假设我有资源是用户并且用户有姓名和年龄。然后我的 REST API 看起来像:

/users/{id}/name
/users/{id}/age

现在,如果我想显示所有名称,我正在考虑使用以下内容:

/users/*/name

这是正确的还是我应该使用其他方式?

编辑 1:添加子资源

从答案中建议使用字段查询参数。但是让我们假设我现在想要一些子资源的属性。例如:

/user/*/name/full
/user/*/name/short

如果我遵循字段选项,我将不得不这样做:

/user?fields=name-short 
/user?fields=name-full 

这不是很好,因为 name 的属性以某种方式链接到 name 类。

请考虑这个例子。试着理解这个想法;)

【问题讨论】:

    标签: rest api design-patterns


    【解决方案1】:

    查询参数

    您可能可以使用通配符,但不能以您在问题中显示的方式使用。如果您想在同一请求中获取除名称之外的更多详细信息怎么办?

    您可以使用 查询参数 来允许为 users 集合选择字段:

    /users?fields=name
    
    /users?fields=age
    
    /users?fields=name,age
    

    或者你可以从partial responses are handled in the Google Drive API的方式中获得一些灵感:

    /users?fields=name(short,full)
    

    或者,您可以使用点表示法

    /users?fields=name.short,name.full
    

    或者混合使用两者,比如Spotify API

    自定义媒体类型

    如果不需要字段选择,可以使用自定义媒体类型returning a predefined set of fields

    【讨论】:

    • 这就是我现在或多或少所做的。但问题是我想以某种方式为该名称添加另一个子资源。这样,一切都是分层的。例如,/users/{id}/name/full 或 short。我知道我可以创建不同的资源,但是看起来不太好。我正在更新我的问题。
    • 提供的 Google Drive API 参考也显示了这一点。
    • 我会听从你的建议,但我仍然不明白为什么我不能使用通配符作为路径参数。此外,我发现stackoverflow.com/questions/207477/… 似乎您可以使用方括号以及许多其他方法来选择一些资源......为什么不 *? ;)
    猜你喜欢
    • 2021-11-08
    • 1970-01-01
    • 1970-01-01
    • 2013-12-01
    • 2010-09-13
    • 2016-07-21
    • 2015-04-28
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多