基于HATEOAS的REST服务如何发现支持的请求头与媒体类型？

针对你提出的问题——如何让客户端发现资源支持的多版本媒体类型（如application/vnd.com.example.resource-v1+json和application/vnd.com.example.resource-v2+json），结合HAL规范的实践方式主要有以下几种：

1. 用HAL的type字段直接声明媒体类型 #

这是最直接的落地方式，把资源支持的每种媒体类型对应成一个超媒体链接，通过type字段明确标注该链接目标对应的MIME类型。客户端可以直接读取这个字段，发起请求时设置对应的Accept头。

示例HAL响应：

{
  "_links": {
    "self": { 
      "href": "/resources/123", 
      "type": "application/vnd.com.example.resource-v2+json" 
    },
    "resource:v1": { 
      "href": "/resources/123", 
      "type": "application/vnd.com.example.resource-v1+json" 
    },
    "resource:v2": { 
      "href": "/resources/123", 
      "type": "application/vnd.com.example.resource-v2+json" 
    }
  },
  "id": 123,
  "content": "v2-specific content"
}

• self链接指向当前响应使用的媒体类型版本；
• 额外的resource:v1/resource:v2链接明确告知客户端该资源还有其他可用版本，type字段直接指定请求时需要的MIME类型。

2. 用profile字段补充媒体类型的语义信息 #

如果你的媒体类型有对应的格式规范（比如v1和v2的字段差异、业务规则），可以用profile字段关联一个内部约定的标识（如URN、规范编号），配合type字段一起使用，帮助客户端理解该媒体类型的具体语义。

示例：

{
  "_links": {
    "resource:v1": { 
      "href": "/resources/123", 
      "type": "application/vnd.com.example.resource-v1+json",
      "profile": "urn:com:example:profiles:resource-v1"
    },
    "resource:v2": { 
      "href": "/resources/123", 
      "type": "application/vnd.com.example.resource-v2+json",
      "profile": "urn:com:example:profiles:resource-v2"
    }
  }
}

• profile的作用是指向媒体类型的语义定义，客户端可以根据这个标识查询内部文档或配置，了解该版本的格式细节。

3. 用OPTIONS请求作为兜底方案 #

虽然HATEOAS优先通过超媒体链接传递信息，但客户端也可以对资源URL发送OPTIONS请求，服务端在响应头中返回支持的媒体类型：

HTTP/1.1 200 OK
Allow: GET, PUT, DELETE
Accept: application/vnd.com.example.resource-v1+json, application/vnd.com.example.resource-v2+json

这是REST的标准机制，和HAL的超媒体信息形成互补，适合客户端需要确认所有支持格式的场景。

4. 自定义链接关系（rel）增强可读性 #

可以使用语义清晰的rel值（如resource:version-1、resource:version-2），配合type字段，让客户端无需额外解析就能快速识别链接对应的媒体类型版本，降低理解成本。

目前行业内的核心实践就是通过HAL链接的type字段直接绑定媒体类型，profile作为语义补充，再结合OPTIONS请求兜底。HAL本身是轻量规范，实践中不需要过度复杂的配置，核心目标是让客户端通过超媒体发现所有可用的资源格式选项。

内容的提问来源于stack exchange，提问作者Gerardo Roza