# \[Proposal\] Link object always have the same data structure

**URL:** https://discuss.jsonapi.org/t/proposal-link-object-always-have-the-same-data-structure/251
**Category:** Uncategorized
**Created:** [December 9, 2015, 6:47am UTC](https://discuss.jsonapi.org/t/proposal-link-object-always-have-the-same-data-structure/251 "2015-12-09T06:47:35Z")
**Posts on this page:** 9
**Page:** 1

<div class="post-metadata">

### Author: ![ubi](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/ubi/32/134_2.png) [@ubi](https://discuss.jsonapi.org/u/ubi)
#### Post date: [December 9, 2015, 6:47am UTC](https://discuss.jsonapi.org/t/proposal-link-object-always-have-the-same-data-structure/251/1 "2015-12-09T06:47:35Z")

</div>

I am currently trying to create my own implementation of [JSON API library](https://github.com/yordis/jsonapi). I notice the spec says that the link value can be a `string` or an `object`.

**Proposal**  
All the links have the same structure: `{ href: '', meta: { ... } }` or `{ href: '' }`

**Reasons**

- Consistency in APIs, easy for consumers
- The Link object should have the same output
- Easy to test/implement
- Non conditional statements for data manipulation (string vs object)

**Examples**

```auto
{
  "self": { "href": "url/to/resource" }
}
{
  "self": { "href": "url/to/resource", meta: { counts: 10 } }
}

```

---

<div class="post-metadata">

### Author: ![eriktrom](https://avatars.discourse-cdn.com/v4/letter/e/e495f1/32.png) [@eriktrom](https://discuss.jsonapi.org/u/eriktrom)
#### Post date: [December 9, 2015, 7:12am UTC](https://discuss.jsonapi.org/t/proposal-link-object-always-have-the-same-data-structure/251/2 "2015-12-09T07:12:04Z")

</div>

I love your passion for convention over configuration.

That said, in the the last 3 points, if you do not have any data to place into the meta object, you’d be left with a) an empty object b) the requirement to put `meta: null` or c) leave out the meta object

Also, the meta object may contain more than one key, which also violates your proposal

Thus, it seems these points

```auto
- The Link object should have the same output
- Easy to test/implement
- Non conditional statements for data manipulation (string vs object)

```

are, for better or worse, un-avoidable, or am I missing some of your argument?

Can you explain more - if so, thanks!

---

<div class="post-metadata">

### Author: ![ubi](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/ubi/32/134_2.png) [@ubi](https://discuss.jsonapi.org/u/ubi)
#### Post date: [December 9, 2015, 7:19am UTC](https://discuss.jsonapi.org/t/proposal-link-object-always-have-the-same-data-structure/251/3 "2015-12-09T07:19:11Z")

</div>

> [@eriktrom](#):
>
> a) an empty object b) the requirement to put meta: null or c) leave out the meta object

**My** preference is C, because I don’t want to send some bites 😃 but with the same output issue probably is better A

> [@eriktrom](#):
>
> meta object may contain more than one key

What do you mean? I don’t understand.

---

<div class="post-metadata">

### Author: ![eriktrom](https://avatars.discourse-cdn.com/v4/letter/e/e495f1/32.png) [@eriktrom](https://discuss.jsonapi.org/u/eriktrom)
#### Post date: [December 9, 2015, 7:33am UTC](https://discuss.jsonapi.org/t/proposal-link-object-always-have-the-same-data-structure/251/4 "2015-12-09T07:33:51Z")

</div>

Well technically the self link (in the spec) doesn’t have a meta object, the related link does. But the general definition of the meta object(which is very open and has no specifics depending on ‘where’ in a json api response its used) says:

```auto
Where specified, a meta member can be used to include non-standard meta-information. The value of each meta member MUST be an object (a "meta object").

Any members MAY be specified within meta objects.

```

Which means its pretty much a free for all key -\> object - so good question in general I’d say, just not sure if there is a way out of that

---

<div class="post-metadata">

### Author: ![ubi](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/ubi/32/134_2.png) [@ubi](https://discuss.jsonapi.org/u/ubi)
#### Post date: [December 9, 2015, 7:40am UTC](https://discuss.jsonapi.org/t/proposal-link-object-always-have-the-same-data-structure/251/5 "2015-12-09T07:40:15Z")

</div>

@eriktrom this is something I dont understand btw

> Note: Additional members may be specified for links objects and link objects in the future. It is also possible that the allowed values of additional members will be expanded (e.g. a **collection link may support an array of values, whereas a self link does not** ).

So `self` link is just a string, `related` have meta with `count`??!?!?!?!? I am lost.

I just see this as `{ href: '...', meta: { whatever you want } }` Do I missing something?

---

<div class="post-metadata">

### Author: ![eriktrom](https://avatars.discourse-cdn.com/v4/letter/e/e495f1/32.png) [@eriktrom](https://discuss.jsonapi.org/u/eriktrom)
#### Post date: [December 9, 2015, 8:07am UTC](https://discuss.jsonapi.org/t/proposal-link-object-always-have-the-same-data-structure/251/6 "2015-12-09T08:07:16Z")

</div>

Yeah this part is confusing I agree. That line (i believe) is saying ‘we might add to what you can put in the links object’. For example they might make to-many relationships be an array of links similar to how the data key is an array when those relationships are embedded in the ‘included’ key of the same payload. This would prevent a trip over the wire just to get the related resource object (which is what the self link inside a relationship object, like comments or author, points too) (just a guess, but i guess that’s the point, its there to note ‘this may be extended in the future, but we don’t know how yet’)

One rule of thumb that may help in general is If you dont think about the links being external (via urls) but instead write the code to handle embedded related resources first. I think it’ll be easier to reason about. At least that helped me. Once that makes sense, then you can limit the size of the initial payload at the cost of making more than one request to fetch the related resources.

Someone should have a better answer than me tomorrow I’d say, but that’s my guess.

FWIW - i just re-read the spec, so worthwhile question indeed.

---

<div class="post-metadata">

### Author: ![eriktrom](https://avatars.discourse-cdn.com/v4/letter/e/e495f1/32.png) [@eriktrom](https://discuss.jsonapi.org/u/eriktrom)
#### Post date: [December 9, 2015, 8:08am UTC](https://discuss.jsonapi.org/t/proposal-link-object-always-have-the-same-data-structure/251/7 "2015-12-09T08:08:12Z")

</div>

yeah and for the meta: { …whatever you want } is correct 🙂 dont use it, unless you see a use case of course 🙂 (pagination might be one)

---

<div class="post-metadata">

### Author: ![ethanresnick](https://avatars.discourse-cdn.com/v4/letter/e/45deac/32.png) [@ethanresnick](https://discuss.jsonapi.org/u/ethanresnick)
#### Post date: [December 15, 2015, 12:19am UTC](https://discuss.jsonapi.org/t/proposal-link-object-always-have-the-same-data-structure/251/8 "2015-12-15T00:19:51Z")

</div>

> [@ubi](#):
>
> I notice the spec says that the link value can be a string or an object.

You’re correct, @ubi.

Of course, allowing the string form makes responses more concise, at the expense that consumers have to support both forms. Whether that’s a good tradeoff is debatable, but at this point, the ship has sailed. That is: if we allowed clients not to support the string form now, that would break their support for APIs that are already using the string form, and JSON API has committed to not making such breaking changes. So this is a non-starter for now, I’m afraid.

---

<div class="post-metadata">

### Author: ![ubi](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/ubi/32/134_2.png) [@ubi](https://discuss.jsonapi.org/u/ubi)
#### Post date: [December 15, 2015, 6:45pm UTC](https://discuss.jsonapi.org/t/proposal-link-object-always-have-the-same-data-structure/251/9 "2015-12-15T18:45:42Z")

</div>

It’s fine.

About the point of changing the spec, that’s a common in software development, nobody should expect that something will be the same the entire time.

I just want to alleviate the pain to everyone, developers and consumers.
