Às vezes, haverá garantias transacionais que você vai querer impor. Por exemplo, no exemplo acima, eu poderia receber as mensagens, solicitar os contatos recentes e essa lista pode ser diferente da lista de URIs de remetente que possuo nas mensagens devido a uma condição de corrida. Nos casos em que é importante garantir esse tipo de atomicidade, você deve incorporar os recursos. Alguns dos formatos hipermídia mencionados acima fornecem um mecanismo para isso. Normalmente, essas situações corresponderão naturalmente a um novo recurso. Lembre-se, você não precisa de uma correspondência 1-1 entre recursos e "entidades" ou qualquer outra coisa. De fato, tal correspondência 1-1 provavelmente significa que você está fazendo algo errado. No geral, porém, você deve tentar minimizar os pontos que precisam de tais garantias transacionais. No exemplo acima, seria desnecessário, pois mesmo que um remetente estivesse faltando na lista de "contatos recentes", eu poderia apenas solicitar suas informações individualmente.
Eu acho que depende das necessidades também. Digamos que o aplicativo cliente esteja exibindo uma lista de 100 elementos e que cada mensagem tenha o remetente exibido. Se colocarmos todos os dados necessários no JSON (ou seja, ID do remetente e nome do remetente), faremos apenas uma solicitação. Se houver links para remetentes, temos 101 solicitações. Não me diga que isso é eficiente:)
Mas concordo que os URIs são uma boa prática, por exemplo, quando você implementa um recurso quando o usuário pode clicar no nome do remetente e ver mais informações sobre ele. Então, minha opinião sobre essa estrutura seria a seguinte:
Boa maneira de programar uma orquestração / processo Uso da ramificação do Git - mantém uma ramificação antiga, nunca mesclada, ou a exclui?