例如，假设我们有一个 restful API 端点来返回订单，它可以以不同的格式输出。
[GET] /orders/42
这可以返回XML，JSON或PDF。
我认为最好的选择，在一个 restful 范式中，可能是在相对 OPTION 调用中将可用类型作为标头返回：
[OPTION] /tests
但我不知道是否存在类似内容协商服务器标头的东西来列出可用的内容类型。
我想它应该看起来像这样：
Available-Content-Types: application/xml,application/json,application/pdf
是否存在类似的东西？
内容协商的工作方式正好相反。
客户端对资源发出请求(通常使用 GET(，并包含一个Accept标头，其中包含可接受的Content-Type列表(使用质量值来描述首选项顺序(。
然后，服务器根据此确定要发送的响应。
因此，客户端可能会发送：
Accept: application/json;q=1, application/xml;q=0.9, application/pdf;0.5, */*;q-0.1
然后，服务器将确定要返回的数据类型。假设所有格式在服务器眼中都同样好，它将返回 JSON，因为它具有来自客户端的最高质量值。
存在类似的东西吗？
不。
内容协商有两种形式。
主动协商涉及将用户代理的首选项编码到初始请求中(使用标头;例如：接受(。 服务器为响应选择合适的表示形式。
反应式协商更接近您正在寻找的内容 - 用户代理根据服务器提供的信息选择资源。
300 多项选择向客户端发出信号，表明有替代表示可用。
300(多选(状态代码指示目标资源具有多个表示形式，每个表示形式都有其自己更具体的标识符，并且正在提供有关替代项的信息，以便用户(或用户代理(可以选择首选 通过将其请求重定向到其中一个或多个标识符来表示。
Location标头用于标识哪个替代项是服务器首选引用，但没有枚举其他替代项的标准。
对于 HEAD 以外的请求方法，服务器应在 300 响应中生成有效负载，其中包含表示元数据和 URI 引用的列表，用户或用户代理可以从中选择最喜欢的一个。 如果用户代理了解提供的媒体类型，则可以自动从该列表中选择。
在网络上，这可能看起来像一个网页，其中编码了链接列表。 浏览器将呈现列表，用户可以选择任何合适的内容。 服务器首选选项也将在位置标头中描述，用户代理可以简单地重定向到该首选选项，而无需先咨询用户。
如果有一个标头可以完成这项工作，您可以在 IANA 标头注册表中找到它;我没有看到任何看起来像匹配的东西，所以它是媒体类型的或什么都没有。