如何解决如何允许客户端在REST API上下文中检索资源的所有可能属性?
| 我正在设计我的第一个RESTful API(具有超媒体约束)。 我不确定我是否正确地提出了问题,但这是一个例子。 假设我有一个产品资源:/products/{id}
响应中有一个product_type元素。
可能的产品类型包括(特定行业)
地板展示
转储显示
轻型散装
...
我的问题是,客户检索产品资源的所有可能属性的最佳方法是什么?
我考虑过要公开一个“元数据”子资源。例如:
product/metadata/type
product/metadata/status
product/metadata/material
product/metadata/color
...对于包含N个项目的每个属性。
恐怕我的解决方案与产品系列过于紧密地结合在一起。我限制了可以在其他上下文(集合)中使用的属性列表。
另一个选择是提供一个包含所有可能属性的元数据集合,但是我不确定这是否是处理它的最佳方法。
任何指针将不胜感激。
解决方法
如何简单地将元数据作为该资源上GET的一部分返回?
例如,如果我得到
/products/123
,则可能会在响应中收到以下有效负载(假设为JSON媒体类型):
{
\"type\" : \"Floor Display\",\"color\" : \"Blue\",\"material\" : \"wood\",...
}
依此类推。现在,如果您需要有关每个属性的更多信息,则可以使每个属性成为下属资源,并返回URI,而不是上面列出的简单值。
编辑:
现在,如果您想让客户端知道所有可能的值,则应在响应之外将其指定为媒体类型文档的一部分。将此类“模式”信息放入您的响应中将不会有用。
同样,HTTP响应可以返回类似200、404、503等的代码,但是该响应并未列出所有可能的代码,也没有定义其语义。相反,这是HTTP规范的工作。
我将采用相同的方法,并在API文档中定义媒体类型的结构和语义,并且仅传输与响应相关的值。我想不出将所有可能的值直接包含在响应中的好处。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。