Qual è il modo corretto di nidificare le risorse nel modello REST?

Sto progettando un'API di servizio REST e mi sono bloccato sul modo corretto di nidificare le risorse.

Risorse: partner, biglietti, impostazioni

Connessioni tra risorse:

il partner ha molti biglietti,
il partner ha una serie di impostazioni,

Logica aziendale:

puoi elencare tutti i partner come utente anonimo,
puoi aggiungere un nuovo ticket al partner specificato come utente anonimo,
solo il partner può elencare i suoi biglietti,
solo il partner può modificare i suoi biglietti,
solo il partner può elencare le impostazioni,
solo il partner può modificare le impostazioni,

Quello che ho fatto fino ad ora:

Risorse per i partner

GET / partner - elenca tutti i partner
GET / partners /: id - mostra i dettagli del partner specificato da: parametro id
GET / partners /: partner_id / ticket - elenco dei biglietti del partner
GET / partner /: partner_id / ticket /: id - dettagli del
POST / partner del biglietto del partner specificato / partner /: partner_id / biglietti - salva il nuovo
PUT del biglietto / partner /: partner_id / biglietti /: id - aggiorna il biglietto specificato da: parametro ID
GET / partners /: partner_id / settings - elenca le impostazioni del partner
PUT / partners /: partner_id / settings - aggiorna le impostazioni del partner

Problema / Domanda

Sarebbe il modo corretto di dividere le risorse nidificate (ticket, impostazioni) per separare le risorse o duplicarle come risorse separate?

Per esempio

GET / biglietti /: ID
POST / biglietti
PUT / biglietti /: id

GET / settings
PUT / settings

api rest api-design

— Przemek
fonte

Odio :

GET /partners/:partner_id/tickets - elenco dei biglietti del partner, ovvero restituisce un elenco di URI, probabilmente del modulo /tickets/:id

GET /partners/:partner_id/tickets/:id - non necessario

POST /partners/:partner_id/tickets - crea un ticket e si associa al partner, restituisce un 201 con il nuovo URI, del modulo /tickets/:id

— Javier
fonte

Adesso capisco di più. Grazie mille :) Ma per quanto riguarda le prestazioni? Supponiamo che sia la situazione: vuoi creare un elenco di biglietti con alcune brevi informazioni. Devi richiedere un elenco di biglietti per il partner e successivamente richiedere ogni singolo biglietto. Ho ragione?

— Przemek,

Beh si. oppure potresti fare in modo che l' /partners/:partner_id/ticketselenco includa alcuni dati utili per ciascun ticket, non solo l'URI canonico del ticket. Ad esempio, in JSON potrebbe essere [{href='/tickets/12',value=10,due='2013-08-13'},{href='/tickets/18',value=7,due='2013-09-02'}], in modo che il client possa mostrare immediatamente qualche tabella e OTTIENI / PUT la / e risorsa / e del ticket completo per ulteriori manipolazioni.

— Javier,

OK È chiaro.

— Przemek,

BTW. Per / partners /: partner_id / ticket i documenti devono essere forniti nella sezione risorse partner o ticket?

— Przemek,

@Javier che ne dici di ELIMINARE? DELETE /tickets/:id?

— Mengdi Gao,