Может ли REST API возвращать несколько ресурсов как один составной ресурс?

Я нахожусь в процессе создания REST API и в настоящее время сталкиваюсь со следующей проблемой:

• Fooэто первый ресурс. Операции CRUD могут применяться через /foo/URI.
• Barэто второй ресурс. Операции CRUD могут применяться через /bar/URI.
• Каждый Fooсвязан с нулем или единицей Bar. Причина, по которой я не рассматриваю себя Barкак подресурс, Fooзаключается в том, что один и тот же Barэкземпляр может использоваться несколькими объектами Foo. Поэтому я решил, что лучше получить к нему доступ через независимый URI, а не /foo/[id]/bar.

Моя проблема в том, что в значительном количестве случаев клиенты, которые запрашивают Fooэкземпляр, также заинтересованы в связанном Barэкземпляре. В настоящее время это означает, что они должны выполнить два запроса вместо одного. Я хочу представить способ, который позволяет получать оба объекта одним запросом, но я не знаю, как смоделировать API для этого. Что я придумал до сих пор:

• Я мог бы ввести параметр запроса , похожий на этот: /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 и перехватывает ответы. Он будет выполнять детализацию вызовов и заполнять детали, прежде чем передать ответ вызывающей стороне.

Это довольно распространенная вещь в REST уровня 3, так как она значительно снижает общение между клиентом и сервером по медленному http. Компания, в которой я работаю, производит API REST уровня 3 именно с этой функцией.

Обновление: для чего оно стоит, вот как это может выглядеть в 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объект туда. Если отношения не существуют, используйте нуль.

Я думаю, что вы думаете об этом :)