root-level link templates

[csantero]

As far as I can tell, the library doesn't support root-level link templates, e.g.

{
    "links": {
        "posts.comments": {
            "href": "/posts/{posts.id}/comments",
            "type": "user"
        }
    },
    "posts": [
        {
            "id": "100",
            "name": "Post 1"
        }, {
            "id": "101",
            "name": "Post 2"
        }
    ]
}

Instead, link templates are included in each resource object, and the values are interpolated in, like so:

{
    "posts": [
        {
            "id": "100",
            "name": "Post 1",
            "links": {
                "comments": {
                    "href": "/posts/100/comments"
                }
            }
        }, {
            "id": "101",
            "name": "Post 2",
            "links": {
                "comments": {
                    "href": "/posts/101/comments"
                }
            }
        }
    ]
}

While there are probably use-cases for the latter, the former has the potential to save considerable amounts of bandwidth and processing time for large result-sets.

[SphtKr]

Agreed, this is not implemented yet. The latter was just simpler to implement and had its roots in an older version of the spec (or possibly pre-spec, from just Ember Data days). It's part of the spec and I'm 👍 for implementing. Suggestions as to where/how?

[SphtKr]

Looks like this is being removed from the spec in json-api/json-api#341, your read?

Top-level links relate to the primary data, including self. Support for URI templates in links has been removed.

[csantero]

Yeah, looks like we can close this. Though it makes me wonder if it's actually a good change; weren't root-level link templates a way to save bandwidth, perhaps even a good amount when returning a large number of resources?

[dgeb]

weren't root-level link templates a way to save bandwidth, perhaps even a good amount when returning a large number of resources?

We had a few issues with root-level link templates:

• We couldn't find a single JSON API implementation that uses them.
• They were limited to saving bandwidth for links, and no other source of repetition in a document. As an alternative, we've considered a top-level templates to provide completely generic templating. This would be both easier to implement and lead to even smaller payloads.
• gzip already saves significant bandwidth from repetition.

Basically, they didn't seem fully baked for 1.0, and we think we might have some better alternatives for later.

[csantero]

Thanks for the explanation, makes sense