Sto lavorando su un'API RESTful, basata sulle risorse e ho una grande entità (un account) con molte proprietà (30, diremo). L'account ha un paio di proprietà che possono essere modificate ...
-
Nome: questo in realtà invia una richiesta (e-mail) affinché una persona confermi l'identità e utilizza un sistema separato per aggiornare il nome.
-
Quantità di risparmio target: è solo un numero che il client può aggiornare per essere quello che vogliono.
Quindi, ecco i miei pensieri erano, e perché non mi piacciono:
1. Unisci PATCH
- PATCH ... / account / {id}
Vorrei prendere un'entità account nel corpo della patch e aggiornare ciò che è cambiato ... che in questo caso può essere solo 2 proprietà (nome / risparmio-obiettivo) e 422 qualsiasi altra modifica.
- Mi piace perché puoi OTTENERE > Modify > PATCH molto facilmente.
- Non mi piace perché una superficie di cambiamento così piccola per una patch di fusione non ha un senso. L'aggiornamento del nome e del target di risparmio allo stesso tempo finisce con una risposta ambigua poiché l'aggiornamento del nome non ha effetto.
2. Aggiornamenti POST
- POST ... / account / {id} / updates / name? value = test
- POST ... / account / {id} /updates/savings-target?value=123.00
Considera gli aggiornamenti come entità e pubblicane di nuovi nell'account.
- Mi piace perché è coerente, pulito, mi consente di gestire le risposte in modo diverso (l'aggiornamento del nome restituisce una sorta di risposta differita come un 204 o qualcosa del genere e un 200 per il target di risparmio).
- Non mi piace perché sembra di cadere in un'API RPC-isque e sto cercando di evitarlo. Trattare gli aggiornamenti come entità sembra janky in quanto non ci sono aggiornamenti a GET. Inoltre, se finisco per aggiungere più campi che possono essere aggiornati, questo diventa brutto molto velocemente.
3. Entità di aggiornamento effettive
- POST ... / account / {id} / updates
- prende un corpo che è probabilmente solo una coppia chiave / valore e restituisce 303 con riferimento a ...
- RICEVE ... / account / {id} / updates / {update-id}
- OTTIENI / account / {id} / aggiornamenti
- anche un endpoint valido che potrebbe restituire tutti gli aggiornamenti creati per questa entità account
Fondamentalmente, 2, ma ho entità reali per gli aggiornamenti a-la CQRS. L'entità di aggiornamento (per mancanza di un nome migliore, al momento) ha uno stato che indica se la modifica è stata completata.
- Mi piace perché modella le modifiche in modo più accurato, credo.
- Non mi piace perché è una soluzione pesante. Per cambiamenti banali come l'obiettivo di risparmio, posso aggiornare l'entità dell'account e completare immediatamente l'entità di aggiornamento che va bene, ma per qualcosa come il nome, non esiste un sistema per richiamare effettivamente l'entità di aggiornamento per completarlo.
Sembra un'imbarcazione carica di eccessivo e molto lavoro solo per avere un'API più pulita. Inoltre, non ho i problemi di throughput che normalmente giustificano quel tipo di architettura.
4. Patch JSON
Come visto qui
- Mi piace perché è uno standard ed è relativamente facile da implementare.
- Non mi piace perché va contro il focus basato sulle risorse dell'API che sto sviluppando (questo è un requisito del business ...).
Aiuto
Non sono vincolato a queste 4 scelte, ma sono le migliori che potrei pensare. Mi sto avvicinando al 2 e cerco di essere convalidato o di fornire una soluzione basata sull'esperienza di qualcun altro che ha riscontrato una situazione simile.