Jestem w trakcie projektowania interfejsu API REST i bycia tak restrykcyjnym, jak tylko się da. Chcę włączyćHATEOAS w odpowiedzi jsona.

Dodawanie adresów URL do pokrewnych zasobów jest dość łatwe, ale pojawiła się dyskusja na temat struktury tych linków.

DUŻO artykułów, które znalazłem, używają pożyczonej strukturyATOM kanały:

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

Pojawiły się pytania:

Po co używać tablicy jako kontenera? Według autora javascript wiem, że dostęp do linków byłby łatwiejszy dzięki linkom jako właściwościom obiektu. Na przykład:

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

Czy istnieje wspólna struktura json (ponownie dostosowując atom)opisać odwołania do właściwości zasobów? (na przykład nadawca wiadomości).

Odnośnik powinien być prawdopodobnie ponownie rozwiązany jako adres URL, ale czy źle byłoby również dołączyć prosty identyfikator? trochę jak:

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

Myślę, że podczas gdy HATEOAS sprawia, że ​​klient nie potrzebuje dużej wiedzy, aby korzystać z API, jestem raczej niechętny, aby usunąć możliwość KORZYSTANIA z tej wiedzy (np. Uzyskiwanie dostępu do obrazu profilu przez budowanie linku po stronie klienta bez uprzedniego sprawdzenia użytkownika).