Qual é a maneira correta de aninhar recursos no modelo REST?

Estou projetando uma API de serviço REST e fiquei preso na maneira correta de aninhar recursos.

Recursos: parceiros, tickets, configurações

Conexões entre recursos:

parceiro tem muitos tickets,
o parceiro definiu configurações,

Lógica de negócios:

você pode listar todos os parceiros como usuário anônimo,
você pode adicionar um novo ticket ao parceiro especificado como usuário anônimo,
único parceiro pode listar seus ingressos,
único parceiro pode modificar seus tickets,
somente o parceiro pode listar configurações,
somente o parceiro pode modificar configurações,

O que eu fiz até agora:

Recursos para parceiros

GET / partners - lista todos os parceiros
GET / partners /: id - mostra detalhes do parceiro especificado por: id parameter
GET / partners /: partner_id / tickets - lista de tickets do parceiro
GET / partners /: partner_id / tickets /: id - detalhes do ticket do parceiro especificado
POST / partners /: partner_id / tickets - salva novo ticket
PUT / partners /: partner_id / tickets /: id - atualiza o ticket especificado por: id parameter
GET / partners /: partner_id / settings - lista as configurações do parceiro
PUT / partners /: partner_id / settings - atualiza as configurações do parceiro

Problema / Pergunta

Seria a maneira correta de dividir recursos aninhados (tickets, configurações) para separar recursos ou duplicá-los como recursos separados?

Por exemplo

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

GET / configurações
PUT / configurações

api rest api-design

— Przemek
fonte

HATEOAS :

GET /partners/:partner_id/tickets - lista de tickets do parceiro, ou seja, retorna uma lista de URIs, provavelmente do formato /tickets/:id

GET /partners/:partner_id/tickets/:id - não é necessário

POST /partners/:partner_id/tickets - cria um ticket e associa-se ao parceiro, retorna um 201 com o novo URI, no formato /tickets/:id

— Javier
fonte

Agora eu entendo mais. Muito obrigado :) Mas e o desempenho? Vamos assumir essa situação: você deseja criar uma lista de tickets com algumas informações breves. Você deve solicitar a lista de tickets para o parceiro e depois solicitar cada ticket individualmente. Estou certo?

— Przemek

bem, sim. ou você pode fazer com que a /partners/:partner_id/ticketslista inclua alguns dados úteis para cada ticket, não apenas o URI canônico do ticket. Por exemplo, em JSON poderia ser [{href='/tickets/12',value=10,due='2013-08-13'},{href='/tickets/18',value=7,due='2013-09-02'}], para que o cliente pudesse mostrar imediatamente alguma tabela e GET / PUT o (s) recurso (s) de ticket completo (s) para manipulação extra.

— Javier

OK Está claro.

— Przemek

Entre. Para / partners /: partner_id / tickets os documentos devem ser fornecidos na seção de recursos do parceiro ou ticket?

— Przemek

@Javier, que tal DELETE? DELETE /tickets/:id?

— Mengdi Gao