Progettazione dell'API REST per associazioni / aggregazione

0

Sto costruendo API RESTful che gestisce persone ed elenchi. Possono esserci molti List e molti Person ciascuno con il proprio set di proprietà. Person può essere in zero o più liste, List può contenere zero o più persone.

Ho implementato queste operazioni per Persone ed elenchi:

  • GET api/Persons/ per ottenere tutte le persone
  • POST api/Persons/ {..} per creare una nuova persona
  • PUT api/Persons/123 {..} per aggiornare persona per id
  • DELETE api/Persons/123 per eliminare persona per id

Per recuperare la lista delle persone è in Vorrei usare GET /api/Persons/123/Lists , per recuperare tutte le persone in Lista I userei GET /api/Lists/234/Persons .

Come faccio a progettare API per aggiungere Person to List, rimuoverle dagli elenchi?

Ho pensato di appiattire Person per includere Lists ma poi ci saranno altre associazioni da Person e non sembra necessario trasferire tali informazioni.

Sto usando asp.net Web API 2 ma in genere chiedo quali siano i principi di progettazione in questo caso.

    
posta Gustas 29.08.2014 - 16:19
fonte

1 risposta

2

Il REST non è scolpito nella pietra e questa relazione molti-a-molti di risorse annidate è un problema molto comune con principalmente due possibili approcci. Quale delle due migliori per il tuo caso specifico dipenderà da alcuni dettagli e forse da come esattamente asp.net gestisce le cose. Ma descriverò entrambi e spiegherò perché preferisco il secondo approccio.

Approccio Uno semplicemente userebbe l'approccio delle risorse annidate che hai già. Facendo

POST /api/Lists/234/Persons/123

aggiungere Persona 123 alla lista 234. Questo è semplice e facile e si potrebbe vedere questo usato abbastanza spesso ma ha alcuni svantaggi. (ovviamente potresti rispecchiare questo e noi POST /api/Persons/123/Lists/234 invece)

La seconda alternativa è gestirla come risorsa del proprio nome ListPersons (come forse hai già chiamato la tabella contenente le informazioni sulla relazione per questo).

Per creare una risorsa del genere:

POST /api/ListPersons?list=234&person=123

simile a eliminare una persona da un elenco o aggiornare la relazione. Mentre all'inizio può sembrare un po 'superficiale, è molto più facile da implementare e testare. Inoltre, mantiene le azioni del controllore più semplici, poiché consente loro di rimanere "a responsabilità unica". Il vantaggio principale potrebbe essere che se in un secondo momento si desidera aggiungere ulteriori dati alla relazione aggiungendo queste informazioni, i parametri saranno semplici e i nomi non possono scontrarsi con nomi simili nelle altre due tabelle.

Ad esempio, supponiamo che una lista sia una squadra e in seguito decidi di aggiungere il "ruolo" che la persona (in questo caso un giocatore) ha in questa squadra. Puoi facilmente aggiungere questo come

POST /api/ListPersons?list=234&person=123&role=captain

anche se la risorsa Persona ha un ruolo (ad esempio il ruolo preferito per questa Persona) da solo.

Almeno in Rails questo ha l'ulteriore vantaggio che all'interno dei controller i nomi delle azioni possono ancora riflettere i verbi REST, mentre nell'approccio uno poiché create ecc sono già stati presi per la Lista stessa, dovresti trovare nuovi nomi.

Per l'approccio alla completezza, tre sarebbero semplicemente aggiornare una lista con un parametro che contiene un elenco di persone. Non mi dispiacerebbe per molti motivi, quindi mi limito a dire che anche questo è visto in the wild.

    
risposta data 29.08.2014 - 19:58
fonte

Leggi altre domande sui tag