我最近一直在设计一个需要RESTful的API，并设法定义一个系统，该系统只使用HTTP头和查询字符串参数来定义元数据，以便响应体可以自由地进行。仅限实际资源数据。
但是我现在正在考虑HATEOAS的链接，并且由于想要保留HTTP标头或查询字符串参数中的所有内容，我决定使用HTTP Link标头字段。
这引发了一个关于rel属性的问题，我找不到直接答案。
我的想法是，对于资源集合，将在响应中发送的Link之一将是：Link: <https://api.domain.com/things/{id}>; rel="..."
这将允许客户端使用RFC6570中定义的简单字符串扩展为集合中的每个资源创建正确的资源URI，而无需将元数据嵌入到每个资源中而无需客户端了解URI模板和资源ID以外的任何内容。
但是，我不确定rel应该在这里，或者它应该指向什么。
在RFC5988中，它表示扩展关系类型必须是URI并且：
虽然URI可以指向a 包含关系语义定义的资源 类型，客户端不应该自动访问该资源以避免 使服务器负担过重。
我的问题是，RESTful API中的定义应该是什么样的？
从外观上看，我可以将rel类似于https://api.domain.com/media/thing，或类似的东西。
但那么实际的定义内容应该是什么？
从技术上讲，它看起来似乎可以是任何东西，例如带有简短解释的纯文本文档。
这些rel属性是否有任何RESTful标准以及它们应该指向什么？
感谢任何帮助。
答案 0 :(得分：0)
查看Richardson's Maturity Model级别3，rel似乎代表已发布链接/关系的名称。在您的情况下，可能会转换为curie:thing-by-id（例如，如果您按照建议的HAL draft中的建议使用curies）。我们的想法是，客户端可以按名称（rel）搜索链接，而无需查看实际的url。