Ricerca dell'approccio RESTful per aggiornare più risorse con lo stesso set di campi

Question

L'attività: dispongo di più risorse che devono essere aggiornate in una chiamata HTTP.

Il tipo di risorsa, il campo e il valore da aggiornare sono gli stessi per tutte le risorse.

Esempio: disporre di un set di automobili in base al proprio ID, è necessario aggiornare lo "stato" di tutte le auto su "venduto".

Classic riposante approccio: richiesta di utilizzo URL qualcosa come PUT/automobili con il corpo JSON come [{id: 1, stato: venduto}, {id: 2, Stato: venduto}, ... ]

Tuttavia, questo sembra essere un eccessivo: troppe volte per mettere stato: venduto

State cercando un modo RESTful (mi riferisco al modo in cui è più vicino al "standard" protocollo di riposo il più possibile) per inviare lo stato : venduto solo una volta per tutte le auto insieme alla lista degli ID auto da aggiornare. Questo è quello che vorrei fare:

PUT/automobili Con JSON {ids = [1,2, ...], lo stato: venduto} ma non sono sicuro se questo è veramente approccio RESTful .

Qualche idea?

anche come un ulteriore vantaggio: Mi piacerebbe essere in grado di evitare JSON per le piccole numero di auto con la semplice creazione di un URL con parametri di qualcosa di simile:?

PUT/auto ids = 1,2 , 3 & stato = venduto

Questo REST è abbastanza?

Answer 1

Un modo ancora più semplice sarebbe solo:

{sold:[1,2,...]} 

Non c'è alcuna necessità di avere più metodi per i numeri più o meno grandi di richieste - è una perdita di tempo di sviluppo e non ha alcun impatto su di noteable prestazioni o la larghezza di banda.

Per quanto riguarda RESTful, purché sia ​​facilmente decifrabile dal destinatario e contenga tutte le informazioni necessarie, non ci sono problemi.

Answer 2

Come ho capito, l'utilizzo di put non è sufficiente per scrivere una singola proprietà di una risorsa. Un'idea è quella di esporre semplicemente la proprietà come risorsa stessa:

Pertanto: PUT/car/carId/status con contenuto del corpo "Venduto".

L'aggiornamento di più di un'auto dovrebbe comportare più posizioni poiché una richiesta deve essere indirizzata a una singola risorsa.

Un'altra idea è di esporre un determinato protocollo in cui si costruisce una risorsa "batch".

contenuti

POST/daily-offerte-report/body { "venduto": [1, 2, 3, 4, 5]}

allora il sistema può semplicemente riconoscere le offerte stati fatti e aggiornare lo stato auto si. In questo modo crei un punto di vista completamente nuovo e abiliti un REST più come api che in realtà intendevi.

Inoltre si dovrebbe pensare di esporre una risorsa elencando tutte le auto che sono disponibili e quindi sono pronti per essere venduti (quindi non venduti, e non necessitano di riparazioni o non sono in affitto).

GET/cars/listino prezzi? City = * -> Elenco di tutte le auto pronte per la vendita, inclusi l'id e il prezzo.

In questo modo un'auto non ha uno stato per quanto riguarda chi possiede l'auto. Una risorsa di solito è indipendente dal suo proprietario (il proprietario aggrega auto non composte da esso).

Ogni volta che si hanno difficoltà a mappare un'operazione su una risorsa, il modello tende a essere imperfetto dal pensiero orientato agli oggetti. Con le risorse molte relazioni (proprietà parent) e proprietà di stato tendono a essere mal collocate poiché la progettazione delle risorse è ancora più astratta di quella dei servizi.

Se è necessario manipolare molti oggetti simili, è necessario identificare il processo aziendale che attiva tali modifiche ed esporre questo processo da una singola risorsa che descrive il proprio input (proprio come il rapporto sugli affari giornalieri).