Why two types of relationships links?

Relationships links may be either “self” or “related” as described here. 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)?
“links”: {
“self”: “… /articles/1/relationships/author”,
“related”: “… /articles/1/author”

this thread might help?

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:


  • links : a links object 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 for the related resources as its primary data. (See Fetching Relationships.)
    • related : a related resource link

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 in the data key of relationship. It is discussed in detail in 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.