Modo RESTful per creare più elementi in una richiesta

Sto lavorando a un piccolo programma client server per raccogliere gli ordini. Voglio farlo in un modo "REST (ful)".

Quello che voglio fare è:

Raccogli tutte le linee d'ordine (prodotto e quantità) e invia l'ordine completo al server

Al momento vedo due opzioni per farlo:

1. Invia ogni orderline al server: POST qty e product_id

In realtà non voglio farlo perché voglio limitare il numero di richieste al server, quindi l'opzione 2:

2. Raccogli tutte le linee d'ordine e inviale subito al server.

Come devo implementare l'opzione 2? un paio di idee che ho sono: avvolgere tutte le orderline in un oggetto JSON e inviarlo al server o utilizzare un array per pubblicare le orderline.

È una buona idea o una buona pratica implementare l'opzione 2 e, in caso affermativo, come dovrei farlo.

Qual è la buona pratica?

Credo che un altro modo corretto di affrontare questo problema sarebbe creare un'altra risorsa che rappresenti la tua raccolta di risorse. Esempio, immagina di avere un endpoint come /api/sheep/{id}e possiamo POST /api/sheepper creare una risorsa pecora.

Ora, se vogliamo supportare la creazione di massa, dovremmo considerare una nuova risorsa per il gregge /api/flock(o /api/<your-resource>-collectionse ti manca un nome più significativo). Ricorda che le risorse non devono essere associate al database o ai modelli di app . Questo è un malinteso comune.

Le risorse sono una rappresentazione di livello superiore, non correlata ai tuoi dati. Operare su una risorsa può avere effetti collaterali significativi, come attivare un avviso per un utente, aggiornare altri dati correlati, avviare un processo di lunga durata, ecc. Ad esempio, potremmo mappare un file system o anche il pscomando unix come API REST.

Penso che sia lecito ritenere che gestire una risorsa possa anche significare la creazione di molte altre entità come effetto collaterale.

Sebbene le operazioni in blocco (ad esempio, la creazione in batch) siano essenziali in molti sistemi, non sono formalmente affrontate dallo stile di architettura RESTful.

Ho scoperto che POST di una raccolta come da te suggerito fondamentalmente funziona, ma sorgono problemi quando è necessario segnalare errori in risposta a tale richiesta. Tali problemi sono peggiori quando si verificano più errori per cause diverse o quando il server non supporta le transazioni. Il mio suggerimento è che se non ci sono problemi di prestazioni, ad esempio quando il provider di servizi è sulla LAN (non WAN) o i dati sono relativamente piccoli, vale la pena inviare 100 richieste POST al server. Mantienilo semplice, inizia con richieste separate e se hai un problema di prestazioni prova a ottimizzare.

Facebook spiega come farlo: https://developers.facebook.com/docs/graph-api/making-multiple-requests

Richieste in batch semplici

L'API batch accetta un array di richieste HTTP logiche rappresentate come array JSON: ogni richiesta ha un metodo (corrispondente al metodo HTTP GET / PUT / POST / DELETE ecc.), Un relative_url (la parte dell'URL dopo graph.facebook. com), un array di intestazioni facoltativo (corrispondente alle intestazioni HTTP) e un corpo facoltativo (per richieste POST e PUT). L'API Batch restituisce un array di risposte HTTP logiche rappresentate come array JSON: ogni risposta ha un codice di stato, un array di intestazioni facoltativo e un corpo facoltativo (che è una stringa codificata JSON).

La tua idea mi sembra valida. L'implementazione è una questione di tua preferenza. Puoi usare JSON o solo parametri per questo (array "order_lines []") e fallo

POST /orders

Dal momento che creerai più risorse contemporaneamente in una singola azione (ordine e le sue linee) è fondamentale convalidare ognuna di esse e salvarle solo se tutte superano la convalida, ad es. dovresti farlo in una transazione.

Immagino sia meglio inviare richieste separate all'interno di una singola connessione . Ovviamente, il tuo server web dovrebbe supportarlo

Ultimamente ho lottato con questo ed ecco a cosa sto lavorando.

Se un POST che aggiunge più risorse ha esito positivo, restituisci 200 OK (stavo considerando un 201, ma l'utente alla fine non atterra su una risorsa che è stata creata) insieme a una pagina che mostra tutte le risorse che sono state aggiunte, sia in lettura -un modo solo o modificabile. Ad esempio, un utente è in grado di selezionare e POSTARE più immagini in una galleria utilizzando un modulo che comprende solo un singolo file di input. Se la richiesta POST riesce nella sua interezza, all'utente viene presentato un insieme di moduli per ciascuna rappresentazione della risorsa immagine creata che gli consente di specificare maggiori dettagli su ciascuna (nome, descrizione, ecc.).

Nel caso in cui non sia possibile creare una o più risorse, il gestore POST interrompe tutta l'elaborazione e aggiunge ogni singolo messaggio di errore a un array. Quindi, viene restituito un 419 Conflict e l'utente viene indirizzato a una pagina di errore 419 Conflict che presenta il contenuto della matrice di errori, nonché un modo per tornare al modulo che è stato inviato.

Non vorrai inviare le intestazioni HTTP per 100 linee d'ordine. Non vuoi nemmeno generare più richieste del necessario.

Invia l'intero ordine in un oggetto JSON al server, a: server / order o server / order / new. Restituisce qualcosa che punta a: server / order / order_id

Considera anche l'utilizzo di CREATE PUT invece di POST