最近，我设计了一个RESTful API，我想使用Link标头字段来实现HATEOAS。
这一切都很好，没有任何实际问题，但我想让API的客户更容易。
例如，Link标题可能如下所示：
Link: <https://api.domain.com/orders/{id}>; rel="https://docs.domain.com/order"
在这种情况下，客户端必须通过在https://docs.domain.com/order属性中搜索rel值来查找链接。
这样可行，但由于文档的URI可能会改变它的脆弱性，并且因为它的长度使得它作为搜索的关键点有点不切实际。
所以我想尝试使用CURIE来改为：
Link: <https://api.domain.com/orders/{id}>; rel="[rc:order]"
这样，大多数情况下都会减少URI更改的问题，并且它更加紧凑，允许客户端更轻松地进行搜索。
我的问题是，由于我使用Link头字段来实现HATEOAS，我觉得将CURIE作为HTTP头字段包含在内而不是在响应中引入元数据是最一致的体。
由于整个API使用所有元数据（分页，版本控制等）的标准HTTP头字段和状态代码，我宁愿不将元数据引入响应主体，只是为了定义一个CURIE。
但是如果我使用HTTP头字段，我应该将哪个字段用于CURIE？
甚至有一种标准方法可以使用HTTP标头字段吗？
如果没有，我是否应该使用自定义标题字段，例如X-Curie: <https://docs.domain.com>; name="rc"，并将其记录在某个地方供客户使用？
我环顾四周，大多数资源都是参考XML或HAL标准，因此有关HTTP头标题字段的任何信息都将受到赞赏。
答案 0 :(得分：0)
不，你不能这样做。链接关系是一个字符串 - 仅此而已。
您应该问自己的问题是您首先使用不稳定的链接关系名称...
答案 1 :(得分：0)
即使您没有使用Link标题，CURIE也无法解决您提出的问题。因为CURIE的标准状态是缩短的URI必须是＆＃34;展开＆＃34;在进行任何比较之前。这也适用于比较相关链接关系。
更实用的方法是投放自己的URI，例如foo:order。然后，您可以使用一些自定义URL缩短方法来解析相关关系的文档URL。这种方法被像HAL+JSON这样的超媒体格式使用（使用curies的HAL格式实际上是误导性的，它只应该用作解析URL到文档的方法）。
答案 2 :(得分：0)
HTTP Link标头rel属性中的CURIE不会被扩展，因为所有rel属性都等同于简单的字符串匹配，没有一个被视为URI。
我主要担心的是“因为文档的URI可能会改变它的脆弱性” - 然后选择一个不会改变的URI。即使您使用重定向到文档深处某个位置的URL，如果您希望客户端开发人员能够解析它，您为链接关系选择的URI也必须是永久性的。