Ich bin gerade dabei, eine REST-API zu entwerfen und so restvoll wie möglich zu sein. Ich möchte einarbeitenHATEOAS in die json Antworten.

Das Hinzufügen von URLs zu verwandten Ressourcen ist recht einfach, es wurde jedoch diskutiert, welche Struktur für diese Links verwendet werden soll.

Viele Artikel, die ich gefunden habe, verwenden eine Struktur, die ich mir geliehen habeATOM Einspeisungen:

"links": [ 
    {"rel": "self", "href":"http://example.org/entity/1"},
    {"rel": "friends", "href":"http://example.org/entity/1/friends"}, ... 
]

Dies warf einige Fragen auf:

Warum ein Array als Container verwenden? Laut einem mir bekannten Javascript-Entwickler wäre der Zugriff auf die Links mit den Links als Eigenschaften eines Objekts einfacher. Zum Beispiel:

"self":    { "href":"http://example.org/entity/1" }, /* (facebook uses this) */  
"friends": { "href":"http://example.org/entity/1/friends", "type": "..."}

Gibt es eine gemeinsame Json-Struktur (neben Atom wieder anpassen)Referenzen in Ressourceneigenschaften zu beschreiben? (zum Beispiel der Absender einer Nachricht).

Die Referenz sollte wahrscheinlich wieder als URL aufgelöst werden, aber wäre es schlecht, auch die einfache ID einzuschließen? eine Art, wie:

"sender": { 
    "id": 12345,
    "href": "resource-uri"
}

Ich bin der Meinung, dass HATEOAS zwar dafür sorgt, dass ein Client nicht viel Wissen benötigt, um eine API zu verwenden, ich aber die Möglichkeit, dieses Wissen zu NUTZEN, nur ungern ausschließt (wie den Zugriff auf das Profilbild durch Erstellen des Links) Client-Seite, ohne den Benutzer zuerst nachzuschlagen).