Esporre endpoint riposante per un uno a molti rapporti

Question

Si consideri la seguente relazione tra due risorse

• Collegio ha molti Facoltà
• Facoltà appartenere ad un collegio

Ovviamente una Facoltà non è una risorsa di prima classe qui.

Ora ho bisogno di endpoint per le seguenti operazioni.

• Creare una nuova facoltà in questo college questa fattoria. Un modo possibile per farlo in due operazioni.
  • POST /faculties/
  • PUT /college/1/faculties
• Rimuovere una facoltà da questo collegio. Ancora due operazioni
  • GET /college/1/faculties: Elenco delle facoltà associate. Ognuna conterrà un auto url come /faculties/1.
  • DELETE /college/1/faculties/1: l'url sembra migliore ma come esporre questo URL?
• Aggiungi una o più facoltà sotto quel collegio.
  • PUT /college/1/faculties che accetta un elenco completo delle facoltà di questo college.
• Elimina completamente quel particolare settore.
  • DELETE /sectors/1: Sembra buono ma deve occuparsi della cache di /faculties/1/sectors.

quello che sarebbe un approccio migliore in questo caso? Ho letto di esporre le risorse dei soci, ma con questo approccio, se un college ha 10 facoltà, ci vorranno 10 chiamate http separate per ottenere tutti quelli dalle iscrizioni.

Inoltre, questa è solo una piccola parte dell'intero albero delle relazioni. Per estendere ulteriormente questo, dire che il sistema ha

• Facoltà ha molti Dipartimenti
• reparto ha molti laboratori così via.

E inoltre, nell'architettura RESTful, il client non deve mai popolare gli URL.

Qualche suggerimento?

Answer 1

Ho scritto un post in passato su come OData implementa tali aspetti (funzionalità "proprietà di navigazione"). Vedi questo link: https://templth.wordpress.com/2014/12/08/updating-data-links-of-odata-v4-services-with-olingo/.

Questo altro collegamento potrebbe inoltre fornire alcuni suggerimenti interessanti poiché descrive alla fine gli URL e i carichi utili corrispondenti: http://www.asp.net/web-api/overview/odata-support-in-aspnet-web-api/odata-v4/entity-relations-in-odata-v4.

Penso che ci siano due casi da sfruttare per ridurre il numero di richieste: lavorare con riferimento o fornire contenuto. Voglio dire se la risorsa rileva (in base al contenuto o un'intestazione personalizzata) il contenuto inviato in modo che sappia se deve solo gestire un riferimento (solo allegato) o un contenuto (creazione e allegato).

vedrei seguendo le possibili richieste di cardinalità multipla (college -> facoltà):

• POST /faculties/: aggiungere una facoltà con nessun attaccamento a un collegio
• POST /college/1/faculties: allegare una facoltà di una scuola e, infine, crearlo se non esiste (in base al contenuto inviato)
• DELETE /college/1/faculties/?ref=/faculties/1 a staccare una facoltà da un college

Qualcosa che potresti anche considerare è mettere il riferimento al college all'interno della facoltà (richiesta POST /faculties). Quindi puoi allegare un elemento durante la sua creazione.

In caso contrario, questo PUT /college/1/faculties mira a sostituire l'intera rappresentazione in modo che tutte le facoltà collegate a un particolare college.

È anche possibile utilizzare un metodo POST o PATCH per minimizzare il numero di richieste. Puoi dare un'occhiata a queste risposte per maggiori dettagli: REST API - Bulk Create or Update in single request e How to Update a REST Resource Collection. Tale approccio ti consente di creare elementi in una chiamata e quindi allegarli. Permette di raccogliere l'elaborazione sugli elementi.

Spero di essere stato chiaro e ti aiuta, Thierry

Answer 2

Usa:

• POST: per creare nuovi record.
• PUT: per modificare i record esistenti.
• CANC: per eliminare i record esistenti.
• GET: per recuperare un singolo o un elenco di record.

Questi sono i metodi standard utilizzati per mantenere i dati persistenti.

E non combinare la relazione di entità con gli indirizzi di endpoint. Tratta ogni entità negli endpoint come se non ci fosse alcuna relazione tra di loro. E sempre al singolare, il tuo endpoint finisce per essere faculty e non faculties.

POST /college/ 
POST /faculty/ 
POST /department/ 
POST /lab/ 

Se è necessario differenziare il ritorno di un elenco di record da un singolo record, sempre restituirà un elenco di record utilizzando GET e restituire un singolo record utilizzando GET con un parametro ID. Lo stesso metodo e lo stesso endpoint possono essere utilizzati per recuperare entrambi (elenco e record singolo). Non è necessario creare endpoint diversi per recuperare elenchi e record singoli.