Atualmente, estou projetando a API para um aplicativo PHP existente e, para esse fim, estou investigando o REST como uma abordagem arquitetural sensata.

Acredito que possuo uma compreensão razoável dos principais conceitos, mas estou lutando para encontrar alguém que tenha abordado hierarquias de objetos e REST.

Aqui está o problema ...

Na hierarquia de objetos de negócios [aplicativo], temos:

Users 
 L which have one-to-many Channel objects
 L which have one-to-many Member objects

No próprio aplicativo, usamos uma abordagem de carregamento lento para preencher o objeto Usuário com matrizes desses objetos, conforme necessário. Acredito que em termos de OO isso é agregação de objetos, mas já vi várias inconsistências de nomenclatura e não quero iniciar uma guerra sobre a convenção de nomenclatura precisa.

Por enquanto, considere que tenho alguns objetos fracamente acoplados que podem ou não ser preenchidos dependendo da necessidade do aplicativo.

Da perspectiva do REST, estou tentando determinar qual deve ser a abordagem. Aqui está o meu pensamento atual (considerando GET apenas por enquanto):

Opção 1 - preencha totalmente os objetos:

GET api.example.com/user/{user_id}

Leia o objeto Usuário (recurso) e retorne o objeto Usuário com todos os possíveis objetos Canal e Membro pré-carregados e codificados (JSON ou XML).

PROS: reduz o número de objetos, não é necessária a passagem de hierarquias de objetos
CONTRAS: os objetos devem ser totalmente preenchidos (caros)

Opção 2 - preencha o objeto principal e inclua links para outros recursos do objeto:

GET api.example.com/user/{user_id}

Leia o objeto Usuário (recurso) e retorne os dados do Usuário preenchidos e duas listas.

Cada lista faz referência ao (sub) recurso apropriado, ou seja,

api.example.com/channel/{channel_id}
api.example.com/member/{member_id}

Eu acho que isso está próximo (ou exatamente) das implicações da hipermídia - o cliente pode obter os outros recursos se quiser (contanto que eu os identifique com sensibilidade).

PROS: o cliente pode optar por carregar os subordinados ou, caso contrário, melhor separação dos objetos como recursos REST
CONTRAS: é necessária mais uma viagem para obter os recursos secundários

Opção 3 - ativar recuperações recursivas

GET api.example.com/user/{user_id}

Leia o objeto Usuário e inclua links para listas de subobjetos, ou seja,

api.example.com/user/{user_id}/channels
api.example.com/user/{user_id}/members

a chamada / channels retornaria uma lista de recursos do canal no formulário (como acima):

api.example.com/channel/{channel_id}

PROS: os recursos primários expõem para onde obter os subodinados, mas não o que são (mais RESTful?), Nenhum requisito para obter os subordinados antecipadamente, os geradores de lista subordinada (/ canais e / membros) fornecem interfaces (como métodos) a resposta mais como serviço.
CONTRAS: agora são necessárias três chamadas para preencher completamente o objeto

Opção 4 - (re) considere o design do objeto para REST

Estou reutilizando a hierarquia de objetos do aplicativo [existente] e tentando aplicá-la ao REST - ou talvez mais diretamente, forneça uma interface API.

Talvez a hierarquia de objetos REST deva ser diferente, ou talvez o novo pensamento RESTful esteja expondo limitações do design de objetos existente.

Qualquer opinião sobre o exposto acima é bem-vinda.

Muito Obrigado

Paulo