Une API REST peut-elle renvoyer plusieurs ressources en une seule ressource composée?

Je suis en train de créer une API REST et actuellement, je rencontre le problème suivant:

• Fooest la première ressource. Les opérations CRUD peuvent être appliquées via l' /foo/URI.
• Barest la deuxième ressource. Les opérations CRUD peuvent être appliquées via l' /bar/URI.
• Tout Fooest associé à zéro ou un Bar. La raison pour laquelle je ne traite pas Barcomme une sous-ressource de Fooest parce que la même Barinstance peut être partagée entre plusieurs mutuels Foo. J'ai donc pensé qu'il valait mieux y accéder via un URI indépendant au lieu de /foo/[id]/bar.

Mon problème est que dans un nombre important de cas, les clients qui demandent une Fooinstance sont également intéressés par l' Barinstance associée . Actuellement, cela signifie qu'ils doivent effectuer deux requêtes au lieu d'une. Je veux présenter un moyen qui permet d'obtenir les deux objets avec une seule requête, mais je ne sais pas comment modéliser l'API pour le faire. Ce que j'ai trouvé jusqu'à présent:

• Je pourrais introduire un paramètre de requête similaire à ceci: /foo/[id]?include_bar=true. Le problème avec cette approche est que la représentation des ressources (par exemple la structure JSON) de la réponse devrait avoir un aspect différent (par exemple, un conteneur tel qu'au { foo: ..., bar: ... }lieu d'être juste un sérialisé Foo), ce qui rend le Foopoint de terminaison de la ressource "hétérogène". Je ne pense pas que ce soit une bonne chose. Lors de la requête /foo, les clients doivent toujours obtenir la même représentation des ressources (structure), quels que soient les paramètres de requête.
• Une autre idée consiste à introduire un nouveau point de terminaison en lecture seule, par exemple /fooandbar/[foo-id]. Dans ce cas, ce n'est pas un problème de retourner une représentation comme { foo: ..., bar: ... }, car alors c'est juste la représentation "officielle" de la fooandbarressource. Cependant, je ne sais pas si un tel point de terminaison d'aide est vraiment RESTful (c'est pourquoi j'ai écrit "can" dans le titre de la question. Bien sûr, c'est techniquement possible, mais je ne sais pas si c'est une bonne idée).

Qu'est-ce que tu penses? Y a-t-il d'autres possibilités?

Une API REST de niveau 3 vous renverrait un Fooet également un lien indiquant le lien Bar.

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

Vous pouvez ensuite ajouter une fonctionnalité "drill down" à votre API qui permet la navigation des liens;

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

La fonction d'exploration descendante se situerait devant les API et intercepterait les réponses. Il effectuerait les appels vers le bas et remplirait les détails avant de remettre la réponse à l'appelant.

C'est une chose assez courante dans le REST de niveau 3 car cela réduit considérablement la conversation client / serveur sur http lent. L'entreprise pour laquelle je travaille produit une API REST de niveau 3 avec exactement cette fonctionnalité.

Mise à jour: pour ce que cela vaut, voici à quoi cela pourrait ressembler dans JSON. C'est ainsi que notre API le structurerait. Notez que vous pouvez imbriquer vos explorations pour extraire des liens de liens, etc.

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..
        }
      ]
    }
  ]
}

Si 95% de toutes les requêtes veulent Fooainsi que Bar, puis il suffit de retourner à l' intérieur de l' Fooobjet lorsque vous demandez un Foo. Ajoutez simplement une propriété bar(ou un autre terme pour la relation) et placez-y l' Barobjet. Si la relation n'existe pas, utilisez null.

Je pense que vous y pensez trop :)