REST API可以将多个资源作为单个复合资源返回吗？

我正在创建REST API，目前，我遇到以下问题：

• Foo是第一资源。可以通过/foo/URI 应用CRUD操作。
• Bar是第二资源。可以通过/bar/URI 应用CRUD操作。
• 每个Foo都与零或一相关联Bar。之所以不将其Bar视为的子资源，Foo是因为Bar可以在Foo多个s 之间共享同一实例。因此，我认为最好通过独立的URI而不是通过URI访问它/foo/[id]/bar。

我的问题是，在很多情况下，请求Foo实例的客户端也对关联的Bar实例感兴趣。当前，这意味着他们必须执行两个查询而不是一个。我想介绍一种允许通过单个查询获取两个对象的方法，但是我不知道如何为此建模。到目前为止，我想出了什么：

• 我可以引入类似于以下内容的查询参数：/foo/[id]?include_bar=true。这种方法的问题在于，响应的资源表示形式（例如JSON结构）将需要看起来不同（例如，容器{ foo: ..., bar: ... }而不是仅序列化的容器Foo），这会使Foo资源端点“异构”。我不认为这是件好事。查询时/foo，无论查询参数如何，客户端都应始终获得相同的资源表示形式（结构）。
• 另一个想法是引入一个新的只读端点，例如/fooandbar/[foo-id]。在这种情况下，返回像这样的表示形式没有问题{ foo: ..., bar: ... }，因为那样的话，它只是fooandbar资源的“正式”表示形式。但是，我不知道这样的辅助端点是否真的是RESTful的（这就是为什么我在问题的标题中写了“ can”的原因。当然，从技术上讲这是可能的，但是我不知道这是一个好主意）。

你怎么看？还有其他可能性吗？

一个3级 REST API将返回你Foo也是一个链接指示相关Bar。

GET /foo/123
<foo id="123">
  ..foo stuff..
  <link rel="bar" uri="/bar/456"/>
</foo>

然后，您可以在API中添加“向下钻取”功能，以允许链接导航；

GET /foo/123?drilldown=bar
<foo id="123">
  ..foo stuff..
  <link rel="bar" uri="/bar/456">
    <bar id="456">
      ..bar stuff...
    </bar>
  </link>
</foo>

向下钻取功能将位于API的前面并拦截响应。在将响应发回给呼叫者之前，它将进行深入查询并填写详细信息。

这在3级REST中是很常见的事情，因为它可以通过较慢的http大大减少客户端/服务器的聊天状态。我工作的公司正是使用此功能生产了3级REST API。

更新： 对于它的价值，这是它在JSON中的外观。这就是我们的API的结构方式。请注意，您可以嵌套钻取以拉出链接等的链接。

GET /foo/123?drilldown=bar

{
  "self": {
    "type": "thing.foo",
    "uri": "/foo/123=?drilldown=bar",
    "href": "http://localhost/api/foo/123?drilldown=bar"
  },
  "links": [
    {
      "rel": "bar",
      "rev": "foo",
      "type": "thing.bar",
      "uri": "/bar/456",
      "href": "http://localhost/api/bar/456"
    }
  ],
  "_bar": [
    {
      "self": {
        "type": "thing.bar",
        "uri": "/bar/456",
        "href": "http://localhost/api/bar/456"
      },
      "links": [
        {
          ..other link..
        },
        {
          ..other link..
        }
      ]
    }
  ]
}

如果所有查询的95％的人希望Foo，以及Bar，然后返回它里面的的Foo对象，当你请求Foo。只需添加一个属性bar（或关系的其他术语），然后将Bar对象放在那里。如果该关系不存在，则使用null。

我认为您对此太想了:)