代码之家 › 专栏 › 技术社区 › Bob Aman

在REST API中处理标志和属性的选项有哪些?

rest api http

Bob Aman · 技术社区 · 14 年前

假设在REST API中有一个复杂的资源。此资源上有多个一对多标志和属性(即,用户可能已将资源评级定为1到5,或用户可能“喜欢”该资源或将其标记为垃圾邮件或忽略该资源,或导致设置其他状态)。

有人提出了一些建议,建议如何在以资源为中心的体系结构中最好地表示这一点,但到目前为止,这些建议都没有真正让我感到高兴。那么,让我们一起来寻找这个;您认为哪些变体最容易理解?我们还没有想到哪些变体?假设一个基于OAuth的API,这里的所有工作都在当前授权用户的上下文中完成。

布尔标志

变体1:

GET /resource/{id}/muted
POST /resource/{id}/muted BODY:true
POST /resource/{id}/muted BODY:false

GET /resource/{id}/muted
PUT /resource/{id}/muted BODY:true
DELETE /resource/{id}/muted

变体3:

GET /resource/{id}/attributes
POST /resource/{id}/attributes BODY:muted=true
POST /resource/{id}/attributes BODY:muted=false

GET /resource/{id}/muted
POST /resource/{id}/mute
POST /resource/{id}/unmute

属性

GET /resource/{id}/rating
POST /resource/{id}/rating BODY:4

变型2:

GET /resource/{id}/rating
PUT /resource/{id}/rating BODY:4
DELETE /resource/{id}/rating

变体3:

GET /resource/{id}/attributes
POST /resource/{id}/attributes BODY:rating=4
POST /resource/{id}/attributes BODY:rating=

思想?建议?其他api是如何处理这个问题的?你是怎么处理的?您是否发现这样的设计问题对开发人员的幸福感或api的易用性有显著影响?

2 回复 | 直到 10 年前

fumanchu 14 年前

从 Roy's dissertation

统一的接口会降低效率,因为信息是以标准化的形式传输的,而不是特定于应用程序需求的形式。REST接口被设计成高效的大粒度超媒体数据传输

GET /resource/{id}/  BODY:{muted: false, like: false, rating: 2, ignored: true}
POST /resource/{id}/ BODY:{muted: true, like: false, rating: 2, ignored: true}
POST /resource/{id}/ BODY:{muted: false, like: false, rating: 2, ignored: true}

一个重要的原因是,RESTful HTTP应用程序的大部分效率来自于缓存,当其构件尽可能大的粒度时,以及当其数据尽可能少的标识符可访问时,这一点最为有效。如果在两个位置都显示“muted”标志 /resource/{id}/ 和 /resource/{id}/muted ,则会出现缓存失效问题。如果你只在 ,那你就不要了。

如果您设计的应用程序的目的是通过小的有效负载来提高效率,那么您就无法从大粒度缓存中获益,而REST架构样式不适合您的应用程序。HTTP可能也不是,但我可以理解,在当今的市场上,人们可能会被它困住。

Lou Franco 14 年前

我喜欢变体3,如果我能同时提供一堆的话——否则,我对1到3之间的值不感兴趣。

而且,绝对没有使用DELETE的东西。