2010-04-16 12 views
14

Tutti gli esempi che ho visto riguardo un'architettura RESTful hanno trattato un singolo record. Ad esempio, una richiesta GET a mydomain.com/foo/53 per ottenere foo 53 o un POST a mydomain.com/foo per creare un nuovo Foo.Record multipli con una richiesta nel sistema RESTful

Ma che dire di più record? Essere in grado di richiedere una serie di Foos per ID o pubblicare una serie di nuovi Foo in generale sarebbe più efficiente con una singola richiesta API piuttosto che dozzine di singole richieste. Vuoi "sovraccaricare" mydomain.com/foo per gestire le richieste per uno o più record? O vorresti aggiungere un mydomain.com/foo-multiple per gestire POST e GET plurali?

Sto progettando un sistema che potrebbe potenzialmente avere bisogno di ottenere molti record contemporaneamente (qualcosa di simile a mydomain.com/foo/53,54,66,86,87) Ma poiché non ho visto alcun esempio di questo, mi chiedo se c'è qualcosa che non sono ottenere un'architettura RESTful che renda questo approccio "sbagliato".

+2

Quello che mi chiedo è che cosa si fa se '53' è' OK', ma '54' è' Not Found'. Dovresti quindi restituire una lista parziale o nulla? –

risposta

6

Mentre non vedo nulla di intrinsecamente sbagliato nel tuo approccio, sembra un po 'strano che un utente della tua API desideri record foo con ID arbitrari. Sospetto immediatamente che stiano utilizzando gli ID per rappresentare un concetto diverso, ad esempio tutti gli foo s creati nell'ultima settimana, ecc. Se è quello che stanno facendo, probabilmente dovresti esporre quella funzionalità sul server invece di utilizzare l'elenco di ID come surrogato.

+0

Sì, questo è un buon suggerimento. Di solito, ci sarà un 'business semantico' che può essere sfruttato per rendere il ricorso N-item più naturale. –

+0

Questo ha senso. Vorresti rendere questo genere di cose disponibile come un'azione separata, come "/ foo/since/2010-04-01"? – keithjgrant

+0

Farei un'azione separata. –

10

C'è una buona ragione per non restituire più record in una singola richiesta, è meno in grado di cache e meno scalabile. Ogni volta che ti chiedi come o perché REST è supposto funzionare, guarda una pagina web. Quando si richiede una pagina, si tratta di collegamenti ad altre risorse come più immagini, file CSS, file js, ecc.

Mentre potrebbe sembrare più efficiente provare a pompare tutti quelli su una singola richiesta, è molto più scalabile e cache-in grado di trattarli tutti come risorse separate e consentire al server Web e alle connessioni keep-alive di gestire la richiesta di molte risorse efficienti. Se hai inalato tutto quel css, javascript e immagini in un singolo download che potrebbe rappresentare l'intera pagina, quando visiti un'altra pagina che ha bisogno di alcune delle stesse risorse, devi scaricarle tutte di nuovo perché non le hai referenziate correttamente come singola risorsa la prima volta che il browser può memorizzare nella cache.

Quando si dispone di qualcosa che rappresenta un elenco di più risorse, il modo per farlo è di fare in modo che l'elenco non sia altro che un elenco di URL delle singole risorse e di recuperarne ciascuna separatamente, proprio come dite che le pagine web sfarfallate contengono URL a tutte le immagini della pagina, non tenta di inserirle tutte nella pagina stessa.

Quando le risorse consentono correttamente la memorizzazione nella cache e vengono referenziate individualmente, la frequenza di risposta della cache può diventare eccessivamente elevata consentendo al server Web di gestire molto più carico e consentendo di nascondere i server proxy tra il client e il server per impedire alla richiesta di dover anche colpire il server. Il web funziona bene usando questo approccio, prima di pensare che suoni pazzo, pensaci.

2

Questa è una vecchia domanda, ma tuttavia, sto scrivendo questo per chiunque possa atterrare qui mentre si cerca una risposta.

Ci sono molti validi motivi per un'applicazione per richiedere più record specificati da ID, e no, non ci deve essere alcuna logica come "creata la scorsa settimana" o "creata tra Data1 e Data2", ecc. Immagina un situazione in cui l'utente viene presentato con una griglia/elenco di record e possono selezionare manualmente più record per un'ulteriore elaborazione.

Detto questo, molte soluzioni sono già suggerito qui: How to construct a REST API that takes an array of id's for the resources

Tuttavia, secondo me la soluzione migliore è quella di @nilesh nella stessa discussione: https://stackoverflow.com/a/32436345/134120

prima fare un POST passando il Gli ID che si desidera ottenere, il server restituirà un ID batch e quindi si esegue un GET con quell'ID batch per ottenere tutti i record.

Problemi correlati