在自定义媒体类型中链接关系粒度与精度？

Question

我正在为RESTful API设计自定义媒体类型,并研究了一些"标准"链接关系的类型和语义含义,以使我的设计具有一定的引导性.

为了演示这个问题,让我说我有一个资源,我可以执行标准的读取,更改,删除方法,并分别使用GET,PUT和DELETE的HTTP惯用法来实现这些方法.

我可以合理地(重新)使用RFC5023中定义的"编辑"链接关系(来自IANA链接注册表),其中规定:

"..."edit"的值指定href属性的值是可编辑成员条目的IRI.当出现在atom:entry中时,href IRI可用于检索,更新和删除资源由该条目代表...."

通过这种方式,用户代理可以理解具有"编辑"关系的链接将允许资源为GET,PUT和DELETEd.

然而,这里存在的问题是,如果编辑资源状态使得资源现在仅支持GET和DELETE操作,则"编辑"关系不再精确.

为了保持我需要的精度i)选项A:指定仅支持GET&DELETE的另一个(复合)链接关系,或ii)选项B:为每个可能的状态转移指定单独的链接并使用适当的链接来指示允许的国家转移.后一种方法提供精确但似乎过于冗长.

或者,(选项C)我可以保持"编辑"关系并接受缺乏精确性,即链接将传达GET,PUT,DELETE语义,但尝试PUT的用户代理将遇到HTTP错误' 405 - 方法不允许'.但是,我对这种方法不满意,因为它意味着客户端不支持状态转换.

总之,问题是平衡链接关系的一般性和精确性的最明智的方法是什么？

Answer 1

经过一番认真的调查后，我得出结论，我正在尝试解决错误的问题。与其关心链接关系定义中 HTTP 动词的粒度，不如关注一个更精细的问题：“HTTP 习语（动词）是否应该合并到链接关系中？”。

我曾使用 AtomPub 作为如何进行链接关系（针对 REST）的参考，结果发现这是一个错误。在AtomPub 邮件存档中，Roy Fielding 建议（用 REST 术语来说）“编辑”方法是错误的，并得出结论认为没有必要。该论点表明还有其他（HTTP）机制来传达此类属性，因此它们在“rel”属性中没有位置。

其他机制在邮件存档中没有明确说明，但我怀疑它们包括以下选项：

1. 让用户代理尝试检查响应（2xx 或 4xx），或者
2. 使用 OPTIONS 向资源询问允许的操作，或者
3. 在成功的 GET 请求中包含“允许”标头，以将允许的资源操作传达给用户代理。

有趣的是，罗伊认为“允许”标头是“超文本的一种形式”。

总而言之，我自己的问题的答案是：

“不要将 HTTP 操作与‘rel’的含义混为一谈”

和

“使用（提供的）HTTP 机制来确定允许的资源操作”

编辑：我应该补充一点，POST 作为数据接收器有一些特殊用途，这些规则需要稍微弯曲，但它们是一种特殊情况。