What is the proper way of nesting resources in REST model?

Question

I'm designing a REST API of service and got stuck on proper way to nest resources.

Resources: partners, tickets, settings

Connections between resources:

• partner has many tickets,
• partner has set of settings,

Bussines logic:

• you can list all partners as anonymous user,
• you can add new ticket to specified partner as anonymous user,
• only partner can list his tickets,
• only partner can modify his tickets,
• only partner can list settings,
• only partner can modify settings,

What I did till now:

Partner resources

GET /partners - list all partners
GET /partners/:id - show details of the partner specified by :id parameter
GET /partners/:partner_id/tickets - list of partner's tickets
GET /partners/:partner_id/tickets/:id - details of the specified partner's ticket
POST /partners/:partner_id/tickets - saves new ticket
PUT /partners/:partner_id/tickets/:id - updates the ticket specified by :id parameter
GET /partners/:partner_id/settings - list partner's settings
PUT /partners/:partner_id/settings - update partner's settings

Problem/Question

Would it be proper way to split nested resources (tickets, settings) to seperate resources or duplicate them as seperate resources?

E.g.

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

GET /settings
PUT /settings

Answer 1

HATEOAS:

GET /partners/:partner_id/tickets - list of partner's tickets, that is, returns a list of URIs, probably of the form /tickets/:id

GET /partners/:partner_id/tickets/:id - not needed

POST /partners/:partner_id/tickets - creates a ticket and associates to the partner, returns a 201 with the new URI, of the form /tickets/:id

• Przemek: Now I understand more. Thanks a lot :) But what about performance? Let assume that situation: you want to create list of tickets with some short informations. You have to request list of tickets for partner and after that request each ticket individualy. Am I right?
• Javier: well, yes. or you could make the /partners/:partner_id/tickets list include some useful data for each ticket, not just the ticket's canonical URI. For example, in JSON could be [{href='/tickets/12',value=10,due='2013年08月13日'},{href='/tickets/18',value=7,due='2013年09月02日'}], so the client could immediately show some table, and GET/PUT the full ticket resource(s) for extra manipulation.
• Przemek: O.K. It's clear.
• Przemek: BTW. For /partners/:partner_id/tickets should docs be provided in partner or ticket resources section?
• Mengdi Gao: @Javier what about DELETE? DELETE /tickets/:id?