REST: più raccolte indipendenti nella stessa radice

Question

REST: più raccolte indipendenti nella stessa radice

#1 da (1 voti)

0

Ho due tipi di risorse: Query e User .

Sono POST ing a /queries per creare una nuova query. e POST ing a /users per creare un nuovo utente.

A quale percorso devo pubblicare, per creare una nuova collezione Query e una nuova collezione User ?

Come da mia comprensione, noi POST a un genitore di risorse / collezioni, per creare quella risorsa / collezione. In questo caso, il genitore per Users e Queries sarebbe lo stesso, se I POST per il genitore, come posso identificare quale raccolta deve essere creata?

Posso usare un percorso di fabbrica per generare queste raccolte, se sì, come?

TL; DR - Io uso /queries e /users per creare rispettivamente Query e User risorsa , quale percorso dovrei usare per creare Queries e Users raccolta ?

EDIT: Sto cercando un consiglio su come questo viene solitamente raggiunto in REST.

rest

posta gaurav5430 26.04.2017 - 15:15

fonte

1 risposta

Leggi altre domande sui tag rest

Progettare una classe (elemento) che applica i bonus a un'altra classe (giocatore) App per pagina singola o applicazione per più pagine?

score 1 · Answer 1

Non sono sicuro di ciò che cerchi di ottenere. Hai detto che hai ancora una sola raccolta in /queries e /users . Quale dovrebbe essere il risultato dell'invio di una nuova collezione?

La nuova raccolta sovrascrive la raccolta attualmente esistente

In questo caso, la nuova collezione sostituisce efficacemente una esistente. In tal caso, direi che PUT richiede a /queries e /users con una nuova raccolta come payload è la strada da percorrere.
Gli elementi della nuova raccolta vengono aggiunti alle voci esistenti

In tal caso, puoi fornire un nuovo endpoint per questo, ad es. POST /queries/bulk con raccolta di query da aggiungere.

Se ci si preoccupa che la raccolta sottostante potrebbe non esistere quando si esegue il POST di un nuovo elemento (singolo) - questo non dovrebbe disturbare affatto l'utente API. GET /queries dovrebbe essere considerato un elenco (forse vuoto), indipendentemente dal fatto che esista o meno qualcosa di fisico. Analogamente, POST /queries dovrebbe sempre funzionare, ed è un lavoro di implementazione dell'API per creare una raccolta fisica sottostante se non esiste.