Estou no processo de projetar uma API REST e ser o mais RESTful possível. Eu quero incorporarHATEOAS nas respostas json.

Adicionar URLs a recursos relacionados é bastante fácil, mas houve alguma discussão sobre a estrutura a ser usada para esses links.

Muitos artigos que encontrei usam uma estrutura emprestada deÁTOMO feeds:

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

Isso levantou algumas questões:

Por que usar uma matriz como um contêiner? De acordo com um desenvolvedor de javascript que conheço, o acesso aos links seria mais fácil com os links como propriedades de um objeto. Por exemplo:

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

Existe uma estrutura json comum (ao lado de adaptar o átomo novamente)descrever referências em propriedades de recursos? (por exemplo, o remetente de uma mensagem).

A referência provavelmente deve ser resolvida como url novamente, mas seria ruim incluir o id simples também? meio que:

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

Minha maneira de pensar é que, enquanto o HATEOAS faz com que um cliente não precise de muito conhecimento para usar uma API, estou relutante em remover a possibilidade de usar esse conhecimento (como acessar a imagem do perfil construindo o link client-side sem procurar primeiro o usuário).