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

Question

我正在为 RESTful API 设计自定义媒体类型，并研究了一些“标准”链接关系的类型和语义，以便为我的设计提供一些指导。

为了演示这个问题，假设我有一个可以执行标准读取、更改、删​​除方法的资源，并且我分别使用 GET、PUT 和 DELETE 的 HTTP 习惯用法来实现这些方法。

我可以合理地(重新)使用 IANA link registry 中定义的“编辑”链接关系(来自 RFC5023)其中指出:

"...The value of "edit" specifies that the value of the href attribute is the IRI of an editable Member Entry. When appearing within an atom:entry, the href IRI can be used to retrieve, update, and delete the Resource represented by that Entry...."

通过这种方式，用户代理可以理解具有“编辑”关系的链接将允许资源被 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 mail archive Roy Fielding 建议(在 REST 术语中)“编辑”的方法是错误的，并得出结论认为这是不必要的。该论点表明还有其他 (HTTP) 机制可以传达此类属性，因此它们在 'rel' 属性中没有位置。

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

让用户代理尝试检查响应(2xx 或 4xx)，或

使用 OPTIONS 向资源询问允许的操作，或

在成功的 GET 请求中包含一个“允许” header 以传达
允许对用户代理进行资源操作。

有趣的是，Roy 认为 'Allow' header成为“一种超文本形式”。

总之，我自己的问题的答案是:

"Do not conflate HTTP operations into the meaning of 'rel' "

和

"Use the (provided) HTTP mechanisms to determine permitted resource operations"

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