Come ha detto @Bart nei commenti, non vi è alcun Santo Graal per questo perché i diversi requisiti guidano scelte e ottimizzazioni diverse.
Detto questo, penso che tu abbia presentato alcune ipotesi su cui mi piacerebbe mettere in discussione le tue riflessioni per aiutarti nel processo decisionale. Passerò attraverso ciascuno con verbi HTTP e URL per essere chiari.
PUT / api / thing. {oggetto completo}
Questo è in genere il punto di partenza predefinito per la maggior parte delle API. Per la maggior parte delle API funziona abbastanza bene, anche con oggetti di grandi dimensioni, perché il client recupera prima la risorsa originale con un GET e quindi riporta indietro l'intero oggetto aggiornato. Normalmente il cliente può semplicemente preoccuparsi di aggiornare le modifiche in memoria e questo mantiene le cose pulite.
Lo svantaggio principale qui è in concomitanza, IMO, in quanto la logica serveride diventa più complicata se si desidera tenere traccia delle modifiche granulari (es. userA ha tirato v1 del documento e modificato campo1 mentre UtenteB ha tirato v1 e modificato il campo 2.). È certamente fattibile unire queste modifiche, ma la normale logica predefinita nella maggior parte dei framework sarà solitamente quella di rifiutare la seconda delle scritture o sovrascrivere la prima, quindi è su di voi fare un'unione significativa se lo si desidera.
PATCH / api / cosa {partial}
In qualche modo non sono d'accordo con la tua affermazione che devi fare diversi DTO qui. Sì, è necessario differenziare i campi eliminati con quelli non modificati, ma è possibile farlo facendo in modo che il client invii esplicitamente un flag per impostare un campo su un valore null, se un dato campo può essere nullo o vuoto. I campi non modificati non devono essere inviati affatto, quindi l'analisi DTO sul server deve essere abbastanza intelligente da farlo ovviamente. È anche importante notare che la convalida deve essere eseguita sull'entità / risorsa modificata, poiché la convalida del DTO-Level è di uso limitato (accetterà solo problemi ingenui come il cattivo formato o i null, non le interazioni più complesse tra i campi)
Infine, penso che ci sia un'opzione di granularità a cui hai accennato di volere ma che non hai incluso (salterò la terza opzione perché sono d'accordo che raramente è la scelta giusta)
PUT / api / impostazioni / profilo
In questo approccio, ogni scheda del riquadro delle impostazioni viene modificata in modo atomico anziché in ciascun campo o in tutta la risorsa delle impostazioni. In molti modi questo è l'approccio più "sintonizzabile", condividendo alcuni dei pro e dei contro degli altri due.