Actualmente estoy diseñando la API para una aplicación PHP existente, y con este fin estoy investigando REST como un enfoque arquitectónico sensible.

Creo que tengo una comprensión razonable de los conceptos clave, pero estoy luchando por encontrar a alguien que haya abordado las jerarquías de objetos y REST.

Aquí está el problema ...

En la jerarquía de objetos de negocio [aplicación] tenemos:

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

En la aplicación en sí, utilizamos un enfoque de carga diferida para llenar el objeto Usuario con matrices de estos objetos según sea necesario. Creo en términos OO, esto es agregación de objetos, pero he visto varias inconsistencias de nomenclatura y no me importa comenzar una guerra sobre la convención de nomenclatura precisa.

Por ahora, considere que tengo algunos objetos poco acoplados que puedo / no llenar según la necesidad de la aplicación.

Desde una perspectiva REST, estoy tratando de determinar cuál debería ser el enfoque. Aquí está mi pensamiento actual (considerando GET solo por el momento):

Opción 1: llenar completamente los objetos:

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

Lea el objeto Usuario (recurso) y devuelva el objeto Usuario con todos los objetos posibles de Canal y Miembro precargados y codificados (JSON o XML).

PROS: reduce el número de objetos, no se requiere atravesar jerarquías de objetos
CONTRAS: los objetos deben estar completamente poblados (caro)

Opción 2: rellene el objeto primario e incluya enlaces a los otros recursos del objeto:

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

Lea el objeto Usuario (recurso) y devuelva el objeto Usuario Datos de usuario rellenados y dos listas.

Cada lista hace referencia al (sub) recurso apropiado, es decir

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

Creo que esto está cerca (o exactamente) de las implicaciones de hipermedia: el cliente puede obtener los otros recursos si lo desea (siempre y cuando los etiquete con sensatez).

PROS: el cliente puede elegir cargar los subordinados o, de lo contrario, una mejor separación de los objetos como recursos REST
CONTRAS: se requiere un viaje adicional para obtener los recursos secundarios

Opción 3: habilitar recuperaciones recursivas

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

Lea el objeto Usuario e incluya enlaces a listas de los subobjetos, es decir

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

la llamada / canales devolvería una lista de recursos del canal en la forma (como arriba):

api.example.com/channel/{channel_id}

PROS: los recursos primarios exponen a dónde ir para obtener los subodinados pero no lo que son (¿más RESTful?), No se requiere que los subordinados estén al frente, los generadores de listas subordinadas (/ canales y / miembros) proporcionan interfaces (como método) La respuesta más como el servicio.
CONTRAS: ahora se requieren tres llamadas para llenar completamente el objeto

Opción 4: (re) considere el diseño del objeto para REST

Estoy reutilizando la jerarquía de objetos de aplicación [existente] e intento aplicarla a REST, o quizás más directamente, proporcionarle una interfaz API.

Quizás la jerarquía de objetos REST debería ser diferente, o tal vez el nuevo pensamiento RESTful esté exponiendo las limitaciones del diseño de objeto existente.

Cualquier idea sobre lo anterior es bienvenida.

Muchas gracias

Pablo