13

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

Improve this question

1 Answer 1

Reset to default
9

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

Improve this answer
6
  • 2
    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?
    – Przemek
    Jul 19, 2013 at 15:20
  • 1
    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.
    – Javier
    Jul 19, 2013 at 15:40
  • O.K. It's clear.
    – Przemek
    Jul 22, 2013 at 9:05
  • BTW. For /partners/:partner_id/tickets should docs be provided in partner or ticket resources section?
    – Przemek
    Jul 22, 2013 at 13:30
  • @Javier what about DELETE? DELETE /tickets/:id?
    – Mengdi Gao
    Aug 18, 2014 at 7:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.