REST: aggiornamento di più risorse con una sola richiesta: è standard o da evitare?

Question

una semplice API REST:

• GET: articoli/{id} - Restituisce una descrizione della voce con il dato id
• PUT: articoli/{id} - aggiornamenti o Crea l'oggetto con il dato id
• DELETE: articoli/{id} - Elimina l'elemento con il dato id

Ora l'API-estensione in questione:

• GET:? Elementi filtranti - Restituisce tutti gli ID elemento corrispondenti al filtro
• PUT: oggetti - aggiornamenti o crea un insieme di elementi come descritto dal payload JSON
• [[CANCELLA: articoli - cancella un elenco di elementi descritti da JSON payload]] < - non è corretto

sto ora interessati al DELETE e mettere funzionalità riciclaggio operazione che può essere facilmente accessibili da PUT/eliminare gli elementi/{id}.

Domanda: è comune fornire un'API come questa?

Alternativa: Nell'era della singola connessione richiesto più l'emissione di richieste multiple è a buon mercato e potrebbe funzionare più atomica dal momento che un cambiamento sia esito positivo o negativo, ma nell'era della banca dati NoSQL un cambiamento nella lista potrebbe essere già happend anche se il richiedere l'elaborazione degli stampi con il server interno o qualsiasi altra ragione.

[UPDATE]

Dopo aver considerato White House Web Standards e Wikipedia: REST Examples seguente esempio API è ora propose:

Un semplice API REST:

• GET: articoli/{id} - Restituisce una descrizione dell'articolo con l'ID specificato
• PUT: articoli/{id} - Aggiorna o crea l'elemento con l'ID specificato
• Elimina: articoli/{id} - Elimina l'elemento con il dato id

Top-risorse API:

• GET:? Elementi filtranti - Restituisce tutti gli ID elemento corrispondenti al filtro
• POST: articoli - Aggiornamenti o crea un insieme di elementi, come descritto dal payload JSON

PUT e DELETE su/oggetti non è supportata e proibito.

L'utilizzo di POST sembra fare il trucco di creare nuovi elementi in una risorsa che racchiude mentre non si sostituisce ma si aggiunge.

HTTP Semantics POST Letture:

Estensione di un database tramite un'operazione di aggiunta

Dove i metodi PUT richiederebbe per sostituire la collezione completa al fine di restituire una rappresentazione equivalente come citato da HTTP Semantics PUT:

Un PUT di successo di una determinata rappresentazione suggerirebbe un successivo GET su tale stessa risorsa di destinazione risulterà in una rappresentazione equivalente restituita in una risposta 200 (OK).

[UPDATE2]

Un'alternativa che sembra ancor più coerente per l'aspetto aggiornamento più oggetti sembra essere il metodo PATCH. La differenza tra il PUT e PATCH è descritto nel Draft RFC 5789 come essendo:

La differenza tra i PUT e patch richieste si riflette nel modo in cui il server elabora l'entità chiusa per modificare la risorsa identificata dal Request-URI. In una richiesta PUT, l'entità inclusa è considerata una versione modificata della risorsa memorizzata sul server di origine e il client richiede che la versione memorizzata venga sostituita. Con PATCH, tuttavia, l'entità inclusa contiene una serie di istruzioni che descrivono come una risorsa attualmente residente sul server di origine dovrebbe essere modificata per produrre una nuova versione. Il metodo PATCH influenza la risorsa identificata dall'URI di richiesta e può anche avere effetti collaterali su altre risorse; Ad esempio, è possibile creare nuove risorse o modificarne quelle esistenti mediante l'applicazione di un PATCH.

Quindi rispetto a POST, PATCH può essere anche un'idea migliore poiché PATCH consente un UPDATE dove come POST consente solo di aggiungere qualcosa che significa aggiungere senza possibilità di modifica.

Così POST sembra essere sbagliato qui e abbiamo bisogno di cambiare il nostro API proposto di:

una semplice API REST:

• GET: articoli/{id} - Restituisce una descrizione della voce con il dato id
• PUT: articoli/{id} - Aggiornamenti o Crea l'elemento con l'id dato
• Elimina: articoli/{id} - Elimina l'elemento con il dato id

Top-risorsa API:

• GET:? Elementi filtranti - Restituisce tutti gli ID elemento corrispondenti al filtro
• POST: articoli - Crea uno o più elementi, come descritto dal payload JSON
• Patch: articoli - Crea o aggiorna uno o più elementi come descritto dal carico utile JSON

Answer 1

È possibile PATCH della raccolta, ad es.

PATCH /items 
[ { id: 1, name: 'foo' }, { id: 2, name: 'bar' } ] 

Tecnicamente PATCH sarebbe identificare il record nella URL (es PATCH /items/1 e non nel corpo della richiesta, ma questo sembra una buona soluzione pragmatica.

Per sostenere la cancellazione, la creazione e l'aggiornamento in un singola chiamata, che non è proprio supportata da convenzioni REST standard di una possibilità è una speciale servizio di "batch" che consente di assemblare le chiamate insieme:.

POST /batch 
[ 
    { method: 'POST', path: '/items', body: { title: 'foo' } }, 
    { method: 'DELETE', path: '/items/bar' } 
] 

che restituisce una risposta con codici di stato per ogni richiesta incorporati :

[ 200, 403 ] 

Non proprio standard, ma l'ho fatto e funziona.

Answer 2

Per quanto ne so il concetto REST copre un aggiornamento di più risorse con una richiesta.In realtà il trucco qui è di assumere un contenitore attorno a quelle risorse multiple e prenderlo come una singola risorsa. Per esempio. si potrebbe semplicemente supporre che l'elenco di ID identifichi una risorsa che contiene diverse altre risorse.

In quelli examples in Wikipedia parlano anche di risorse in Plurale.