I have a few HTTP resources, and i'm wondering if including the models of one in the other is acceptable or if there is a cleaner method.In this example, we have a ton of news resources, and users can subscribe via a resource called subscription:==>/news-items/{id}/{    id: 987,    url: http://example.com/foo/bar,    title: Wow! A Headline,}And==> /users/{user-id}/subscriptions/[    {         id : 123         keywords: Mr Celebrity    },    ...]And then the endpoint that includes the models of both resources ...==> /users/{user-id}/my-news/[    {        id: 987,        url: http://example.com/foo/bar,        title: Wow! A Headline,        matched_by: [            {                id: 123,                keywords: Wow,            },            ...        ]    },    ...]The usecase is fairly self explanatory for this: A feed of news with 'matched by Mr Celebrity' next to it. It feels a bit weird to have an endpoint that consists only of nested/composite models from other endpoints ... Is this acceptable practice or problematic?The endpoint will be read-only, and the other options seem to be:HATEOAS-style: matched_by and the news item are URLs pointing to a news item and subscription. Would require more HTTP requests.Some kind of multi-payload response with a HATEOAS primary payload then 'related' payload of the referenced resources. Not seen this done before.??? some other options?If my approach is sound, great, but I want to hear what others would do if there is a better alternative.Thanks :)
RESTful composition/inclusion of other resources
design patterns;rest;http
A feed of news with 'matched by Mr Celebrity' next to it. It feels a  bit weird to have an endpoint that consists only of nested/composite  models from other endpoints ... Is this acceptable practice or  problematic?Having embedded resource representations is perfectly valid, since you describe a resource graph in where every resource can be connected to another resources...If I were you I'd check some standard hypermedia type instead of creating an own. For example: JSON-LD, HAL, Collection+JSON, etc...HATEOAS-style: matched_by and the news item are URLs pointing to a  news item and subscription. Would require more HTTP requests.HATEOAS is about using hyperlinks, not plain URLs. Don't confuse these terms... A hyperlink consists of at least a HTTP method (calling an operation) and an URL (on a resource). By REST you have to add some meta-data to it, for example link relation or Hydra:Operation (if you prefer RDF).Just a copy-paste HAL example from one of the linked sites:{    _links: {        self: { href: https://api.example.com/player/1234567890/friends },        next: { href: https://api.example.com/player/1234567890/friends?page=2 }    },    size: 2,    _embedded: {         player: [            {                 _links: {                     self: { href: https://api.example.com/player/1895638109 },                    friends: { href: https://api.example.com/player/1895638109/friends }                },                playerId: 1895638109,                name: Sheldon Dong,                alternateName: sdong,                image: https://api.example.com/player/1895638109/avatar.png            },            {                 _links: {                     self: { href: https://api.example.com/player/8371023509 },                    friends: { href: https://api.example.com/player/8371023509/friends }                },                playerId: 8371023509,                name: Martin Liu,                alternateName: mliu,                image: https://api.example.com/player/8371023509/avatar.png            }        ]    }}As you can see this defines one size property and two embedded players for a collection resource. Every representation contains links. You can find the main resource identifier (URI) under the links having self link relation. This is just one example. Most of the generic hypermedia types use similar approaches. Btw. this is just the GET part of the story. (HAL does not support POST, PUT, DELETE links, you have to use an extension to describe them.)Understanding a better solution, like RDF with JSON-LD and Hydra would be a longer story...