# Why two types of relationships links?

**URL:** <https://discuss.jsonapi.org/t/why-two-types-of-relationships-links/2056>\
**Category:** Uncategorized\
**Created:** [September 27, 2020, 8:11am UTC](https://discuss.jsonapi.org/t/why-two-types-of-relationships-links/2056 "2020-09-27T08:11:40Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![gdj](https://avatars.discourse-cdn.com/v4/letter/g/58956e/32.png) [@gdj](https://discuss.jsonapi.org/u/gdj)\
**Post date:** [September 27, 2020, 8:11am UTC](https://discuss.jsonapi.org/t/why-two-types-of-relationships-links/2056/1 "2020-09-27T08:11:40Z")

</div>

Relationships links may be either “self” or “related” as described [here](https://jsonapi.org/format/#document-resource-object-relationships). I’ve read the explanations but I still don’t understand why there is a need for two links, and what the difference is. Also, by principle, shouldn’t a relationship be handled as any resource representation with one url, and then the verb would be used to instruct the action?  
Changes to relationships via such links, are they limited to create/delete of the linkage only (not creating/deleting the related resource itself)?  
Example:  
“links”: {  
“self”: “… /articles/1/relationships/author”,  
“related”: “… /articles/1/author”  
}

---

<div class="post-metadata">

**Author:** ![bokara](https://avatars.discourse-cdn.com/v4/letter/b/ea5d25/32.png) [@bokara](https://discuss.jsonapi.org/u/bokara)\
**Post date:** [October 21, 2020, 7:56pm UTC](https://discuss.jsonapi.org/t/why-two-types-of-relationships-links/2056/2 "2020-10-21T19:56:38Z")

</div>

[this thread](https://discuss.jsonapi.org/t/self-vs-related-links-and-what-to-return/1236/9) might help?

---

<div class="post-metadata">

**Author:** ![jelhan](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/jelhan/32/822_2.png) [@jelhan](https://discuss.jsonapi.org/u/jelhan)\
**Post date:** [December 13, 2020, 3:20pm UTC](https://discuss.jsonapi.org/t/why-two-types-of-relationships-links/2056/3 "2020-12-13T15:20:24Z")

</div>

The `self` link represents the relationship itself, while the `related` link points to the associated resource(s).

This is the relevant part of the specification:

> **Relationships**  
> […]
> 
> - `links` : a [links object](https://jsonapi.org/format/#document-links) containing at least one of the following:
> - `self` : a link for the relationship itself (a “relationship link”). This link allows the client to directly manipulate the relationship. For example, removing an `author` through an `article` ’s relationship URL would disconnect the person from the `article` without deleting the `people` resource itself. When fetched successfully, this link returns the [linkage](https://jsonapi.org/format/#document-resource-object-linkage) for the related resources as its primary data. (See [Fetching Relationships](https://jsonapi.org/format/#fetching-relationships).)
> - `related` : a [related resource link](https://jsonapi.org/format/#document-resource-object-related-resource-links)

The return different information on `GET`:

- A relationship link returns a “relationship data”. This is the same data as could be used for [Resource Linkage](https://jsonapi.org/format/#document-resource-object-linkage) in the `data` key of relationship. It is discussed in detail in [Fetching Relationships](https://jsonapi.org/format/#fetching-relationships) section of the specification.
- A related resource link “provides access to resource objects linked in a relationship”. While the relationship link returns the identifier only the related resource link returns full resource objects including the fields.

For related resource links only `GET` is specified. For relationship links also `POST`, `PATCH` and `DELETE` are specified.

Using `POST`, `PATCH` and `DELETE` methods a relationship link allows the modification of a relationship. E.g. an existing resource can be associated or removed from that relationship. This is especially helpful for manipulation of a has-many relationship. If manipulating a relationship by updating the resource itself a client must replace all related resources. Relationship links allow to patch a relationship, which mitigates the risk of collisions by concurrent write requests.