我正在设计我的第一个RESTful API（使用超媒体约束）。
我不确定我是否正确地提出了问题，但这是一个例子。
假设我有一个产品资源：
/products/{id}
响应中有一个product_type元素。
可能的产品类型包括（行业特定的）
我的问题是，客户端检索产品资源的所有可能属性的最佳方法是什么？
我考虑过暴露“元数据”子资源。例如：
product/metadata/type
product/metadata/status
product/metadata/material
product/metadata/color
...对于包含N个项目的每个属性。
我担心我的解决方案与产品系列紧密耦合。我限制可以在另一个上下文（集合）中使用的属性列表。
另一种选择是提供包含所有可能属性的元数据集合，但我不确定这是否是处理它的最佳方式。
任何指针都将非常感激。
答案 0 :(得分：1)
如何简单地将元数据作为该资源上的GET的一部分返回？
例如，如果我获取/products/123，我可能会在响应中收到以下有效内容（假设为JSON媒体类型）：
{
"type" : "Floor Display",
"color" : "Blue",
"material" : "wood",
...
}
等等。现在，如果您需要有关每个属性的更多信息，那么您可以使每个属性成为从属资源并返回URI，而不是我上面列出的简单值。
编辑：
现在，如果您想让客户端了解所有可能的值，那么应该在您的响应之外指定，作为媒体类型文档的一部分。将这种“模式”信息放入您的回复中并没有用。
同样，HTTP响应可以返回200,404,503等代码，但响应不会列出所有可能的代码，也不会定义它们的语义。相反，这是HTTP规范的工作。
我会采用相同的方法，在API文档中定义媒体类型的结构和语义，并仅传输与响应相关的值。我想不出将所有可能的值直接包含在响应中的任何好处。