¿Cuál es la forma correcta de anidar recursos en el modelo REST?

Estoy diseñando una API de servicio REST y me atasqué en la forma adecuada de anidar recursos.

Recursos: socios, entradas, configuraciones

Conexiones entre recursos:

el compañero tiene muchas entradas,
el socio tiene una configuración,

Lógica de negocios:

puede enumerar todos los socios como usuario anónimo,
puede agregar un nuevo ticket al socio especificado como usuario anónimo,
solo el socio puede listar sus boletos,
solo el socio puede modificar sus boletos,
solo el socio puede enumerar la configuración,
solo el socio puede modificar la configuración,

Lo que hice hasta ahora:

Recursos de socios

GET / partners - enumera todos los socios
GET / partners /: id - muestra detalles del socio especificado por: parámetro id
GET / partners /: partner_id / tickets - lista de tickets de
socios GET / partners /: partner_id / tickets /: id - detalles del ticket del socio especificado
POST / partners /: partner_id / tickets - guarda el nuevo ticket
PUT / partners /: partner_id / tickets /: id - actualiza el ticket especificado por: parámetro id
GET / partners /: partner_id / settings - enumera la configuración del asociado
PUT / partners /: partner_id / settings - actualiza la configuración del socio

Problema / Pregunta

¿Sería la forma correcta de dividir los recursos anidados (tickets, configuraciones) para separar los recursos o duplicarlos como recursos separados?

P.ej

GET / tickets /: id
POST / tickets
PUT / tickets /: id

GET / settings
PUT / settings

api rest api-design

— Przemek
fuente

HATEOAS :

GET /partners/:partner_id/tickets - lista de tickets de socios, es decir, devuelve una lista de URI, probablemente de la forma /tickets/:id

GET /partners/:partner_id/tickets/:id - innecesario

POST /partners/:partner_id/tickets - crea un ticket y se asocia al socio, devuelve un 201 con el nuevo URI, del formulario /tickets/:id

— Javier
fuente

Ahora entiendo más. Muchas gracias :) ¿Pero qué pasa con el rendimiento? Supongamos esa situación: desea crear una lista de tickets con información breve. Debe solicitar la lista de entradas para el socio y, después de eso, solicitar cada entrada individualmente. Estoy en lo cierto?

— Przemek

bueno, sí. o puede hacer que la /partners/:partner_id/ticketslista incluya algunos datos útiles para cada ticket, no solo el URI canónico del ticket. Por ejemplo, en JSON podría ser [{href='/tickets/12',value=10,due='2013-08-13'},{href='/tickets/18',value=7,due='2013-09-02'}], por lo que el cliente podría mostrar inmediatamente alguna tabla y OBTENER / PONER los recursos completos del ticket para una manipulación adicional.

— Javier

OK está claro.

— Przemek

Por cierto. Para / partners /: partner_id / tickets ¿se deben proporcionar los documentos en la sección de recursos para socios o tickets?

— Przemek

@Javier, ¿qué hay de DELETE? DELETE /tickets/:id?

— Mengdi Gao