JSON-API-Self-vs-bezogene Links für Beziehungen URLs

Question

Was ist der Unterschied zwischen dem self-Link und dem related-Link für JSON-API?

Answer 1

Ich hatte so viele Schwierigkeiten, eine einfache, lesbare Antwort auf das zu finden, was ich tatsächlich auf die Antwort zurücksende.

Für das Beispiel bei JSON API sie haben folgende JSON:

{ 
    "links": { 
    "self": "http://example.com/articles", 
    "next": "http://example.com/articles?page[offset]=2", 
    "last": "http://example.com/articles?page[offset]=10" 
    }, 
    "data": [{ 
    "type": "articles", 
    "id": "1", 
    "attributes": { 
     "title": "JSON API paints my bikeshed!" 
    }, 
    "relationships": { 
     "author": { 
     "links": { 
      "self": "http://example.com/articles/1/relationships/author", 
      "related": "http://example.com/articles/1/author" 
     }, 
     "data": { "type": "people", "id": "9" } 
     }, 
     "comments": { 
     "links": { 
      "self": "http://example.com/articles/1/relationships/comments", 
      "related": "http://example.com/articles/1/comments" 
     }, 
     "data": [ 
      { "type": "comments", "id": "5" }, 
      { "type": "comments", "id": "12" } 
     ] 
     } 
    }, 
    "links": { 
     "self": "http://example.com/articles/1" 
    } 
    }], 
    "included": [{ 
    "type": "people", 
    "id": "9", 
    "attributes": { 
     "first-name": "Dan", 
     "last-name": "Gebhardt", 
     "twitter": "dgeb" 
    }, 
    "links": { 
     "self": "http://example.com/people/9" 
    } 
    }, { 
    "type": "comments", 
    "id": "5", 
    "attributes": { 
     "body": "First!" 
    }, 
    "relationships": { 
     "author": { 
     "data": { "type": "people", "id": "2" } 
     } 
    }, 
    "links": { 
     "self": "http://example.com/comments/5" 
    } 
    }, { 
    "type": "comments", 
    "id": "12", 
    "attributes": { 
     "body": "I like XML better" 
    }, 
    "relationships": { 
     "author": { 
     "data": { "type": "people", "id": "9" } 
     } 
    }, 
    "links": { 
     "self": "http://example.com/comments/12" 
    } 
    }] 
} 

Diese Zeile hier:

"self": "http://example.com/articles/1/relationships/author"

Ist eine "Beziehung link"

Diese Zeile hier:

"self": "http://example.com/articles/1/relationships/comments"

Ist auch eine „Beziehung Link“

Ja, ich weiß, es ist verwirrend, da der andere related genannt wird. Was ist der Zweck dieser Links? Der Zweck ist nur verwalten Sie die Beziehungen. Also sagen Sie, Sie tun eine GET /articles/1/relationships/comments Sie tun nicht geben Sie die Informationen der Kommentare zurück. Sie nur geben Sie ein Array von Ressourcen-Typen/IDs und einige andere Sachen, wie Metadaten und Links. Beispiel:

{ 
    "data": [{ 
    "type": "comments", 
    "id": "13" 
    }, { 
    "type": "comments", 
    "id": "29" 
    }], 
    "links": { 
    "self": "http://example.com/articles/1/relationships/comments", 
    "next": "http://example.com/articles/1/relationships/comments?page[offset]=2", 
    "last": "http://example.com/articles/1/relationships/comments?page[offset]=4" 
    }, 
    "meta": { 
    "copyright": "Copyright 2015 Example Corp.", 
    "authors": [ 
     "Zach Aysan" 
    ]} 
} 

Warum ist das nützlich? Weil wir manchmal wollen nur löschen Sie die Beziehung, nicht die Ressource (Kommentar, Autor) selbst. Wenn wir zum Beispiel eine DELETE /articles/1/relationships/author erstellen würden, die den Benutzer nicht aus der Benutzertabelle löscht, würde er diesen Benutzer einfach als Autor entfernen. Um nur einige Kommentare zu löschen, machen wir eine PATCH /articles/1/relationships/comments und fügen nur die Kommentare ein, die wir behalten möchten. Denken Sie jedoch daran, dass das Backend die tatsächlichen Kommentare löschen kann, wenn es das für richtig hält. (Seit was gut sind Kommentare ohne einen zugehörigen Artikel?)

Was ist mit dem anderen Link? Warum ist es /articles/1/author anstelle von /people/9? Da der Autor eines Artikels zwischen Anforderungen ändern kann und GET /articles/1/author wird immer den aktuellen Autor zurückgeben. Aus diesem Grund müssen wir normalerweise keine Dinge wie PATCH /articles/1/author unterstützen, da es normalerweise sinnvoller ist, die Änderung an der Ressource selbst zu steuern. PATCH /people/9, wenn zum Beispiel jemand seinen Avatar ändert, während er auf der Seite Artikel bearbeiten ist. Auch wenn ein Admin die Autorenschaft des Artikels geändert hat, ging die PATCH noch an die richtige Ressource.

Ich weiß. Es ist alles ein bisschen langweilig, aber sobald alles verstanden wird, sollten Dinge wie Ember Data einfach zusammenschnappen.