Manipola i dati del database attraverso la richiesta dell'API REST singola o Più richieste conseguenti?

Come @Laiv afferma nel suo commento, dovresti pensare a come vuoi che venga consumato. In che modo l'utente dell'API desidera che funzioni? Sarà dall'altra parte dell'API più vantaggioso eseguire una o più azioni per fare ciò?

Non possiamo parlare per ciò che è meglio nel tuo caso.

Detto questo, di solito preferisco il singolo endpoint che si prende cura di queste azioni in un colpo solo. Questo per ridurre la quantità di richieste che vengono fatte in quanto le convalide, il codice e gli aggiornamenti del database in genere sono meno costosi per queste azioni rispetto al viaggio andata e ritorno effettuato dal server. Si riduce davvero a se si vuole ridurre la latenza a scapito di, ciò che sembra dalla tua domanda, una certa complessità del codice o è la manutenzione del tuo codice più importante? Ci sono ovviamente alcuni altri fattori qui, ma penso che tu stia prendendo la mia direzione.

Inoltre, nulla ti impedisce di implementare entrambi i casi se riesci a trovare due casi d'uso ottimali per entrambi in situazioni diverse, anche se dovrai documentare chiaramente i loro diversi casi d'uso in modo semplice e comprensibile.

Molte cose possono andare storte tra client e server. Mi assicurerei sempre che una richiesta non possa mai mettere il DB in uno stato errato. Quindi: se group deve essere modificato su PUT /user , fallo. Non dare per scontato che il client sia in grado di richiedere anche PUT /group !

Il risultato di una richiesta dovrebbe essere sempre atomico.

Un altro modo per pensarlo è l'idea di una nozione più formale di più comandi in una richiesta, piuttosto che più o meno hard coding su /user . Quindi, avresti i primitivi, /user e /group , ma anche un modo di fare una richiesta estesa che copra gli aggiornamenti ad entrambi.

Con REST otteniamo la nostra mentalità bloccata in una modalità di pensiero CRUD, che a volte ci porta a risolvere problemi con hack una tantum anziché aumentare il livello di astrazione.

Come alternativa più formale, c'è un'estensione, OData , che offre un modo standardizzato di fornire (mancante o altrimenti non standardizzati) in cima agli endpoint della risorsa orientata CRUD di REST.

Per prima cosa, queste funzionalità mancanti includono join per le query, il che significa che il client non deve effettuare più richieste per richieste che riguardano diverse risorse. Per un altro, OData include la possibilità di impacchettare più comandi di aggiornamento in una singola richiesta (che forse tutti hanno successo o falliscono tutti). OData fornisce una sintassi pensata e standardizzata per rappresentare queste cose (inoltre ci sono alcune librerie disponibili).

Nel CRUD generale, come qualsiasi altra funzionalità di base, gestisce un gran numero di casi d'uso senza estensione, sebbene alcuni casi d'uso del dominio dell'applicazione richiedano semplicemente che il client realizzi join e / o transazioni.

Posso certamente apprezzare che OData potrebbe essere eccessivo per questa sola domanda, anche se ti incoraggio ad essere consapevole di questo come un modo per aumentare il livello di astrazione con cui abbiamo a che fare.