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

假设在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的易用性有显著影响?