【问题标题】:Should a REST API resource do authorization based on query parameters?REST API 资源是否应该根据查询参数进行授权?
【发布时间】:2021-09-11 23:40:49
【问题描述】:

对于列出资源的 RESTful API,我有一个方法如下:

GET - /cars

它返回一个汽车列表,可能还有一个分页标记。

我想提供一个查询参数来过滤这些结果,例如make。例如:GET - /cars?make=Toyota

但是,由于我正在使用的系统的技术限制,此查询参数只能提供给具有一定权限的用户,具体取决于他们的角色。

如果有这样的 API 资源基于请求有效负载(而不仅仅是资源)进行授权,那么它是 RESTful 吗?

另一种方法似乎是支持make 查询参数的单独资源GET - /cars/filter。但是,我不确定如何命名此资源,因为 filter 是动词,而不是名词。

【问题讨论】:

  • 关于 REST 的原始论文和 RFC 7231 都没有说明必须如何进行授权。回答标题中的问题:绝对可以。实际上,filter 也是一个名词 ;)

标签: rest api-design


【解决方案1】:

如果有这样的 API 资源基于请求有效负载(而不仅仅是资源)进行授权,那么它是 RESTful 吗?

短版:是的,当然。

当服务器响应(例如)403 Forbidden 时,服务器拒绝授权请求。这可能是因为请求不包含与资源匹配的授权元数据,也可能是其他原因。

加长版:

GET /cars?make=Toyota

对于这个请求,request-target,我们从中计算 effective request uri包括查询部分。换句话说,/cars/cars?make=Toyota 标识不同的资源。

当然,在我们的资源模型中,Bob 可能被授权访问 /cars 而不是 /cars?make=Toyota(反之亦然)。

在您喜欢的框架中实现这些控件可能会也可能不会直接,但就 API 设计而言,这很好。


另一种选择似乎是支持 make 查询参数的单独资源 GET - /cars/filter。

这也是一个非常令人满意的选择。

我不知道如何命名这个资源,因为 filter 是动词,而不是名词。

不用担心 - REST 不关心您为资源标识符使用的拼写约定。

如果您尝试单击该链接,您会发现它的工作方式与您预期的完全一样,即使拼写包含动词。

【讨论】:

    猜你喜欢
    • 2021-07-26
    • 1970-01-01
    • 2018-10-11
    • 2018-12-09
    • 2017-01-16
    • 1970-01-01
    • 2019-05-23
    • 1970-01-01
    • 2020-01-31
    相关资源
    最近更新 更多