come definire un PATCH HTTP per modificare più entità in una richiesta

Question

come definire un PATCH HTTP per modificare più entità in una richiesta

#1 da (1 voti)
#2 da (0 voti)

0

Sto cercando qualche consiglio per quanto riguarda le migliori pratiche per costruire una richiesta HTTP PATCH in grado di modificare più entità in una richiesta. La ragione per cui la sto chiedendo è perché per me l'API di Rest è piuttosto vaga e non ho molta esperienza nella creazione di API di Rest.

Il mio approccio sarebbe quello di creare una richiesta con questi dati:

[
    {
        id:<entity id to update>, 
        patch: 
        {
            op: <patch operation>,
            path: <field to update>,
            value: <new value>
        }
   },
   ...
]

Che cosa pensi e cosa consiglieresti in base alla tua esperienza?

grazie mille

http-request rest

posta Manuel Sopena Ballesteros 08.01.2018 - 13:23

fonte

2 risposte

Leggi altre domande sui tag http-request rest

In che modo la lista nera e l'accesso ai blocchi di accesso sono immuni tramite JWT? Invia record utilizzando la modalità asincrona o di sincronizzazione

score 1 · Answer 1

I am looking for some advice in regards of best practices to build a HTTP PATCH request that can edit multiple entities in one request.

RFC 6902 , descrive la patch JSON e funge da buon riferimento per la progettazione di un documento di correzione.

Fondamentalmente, il documento di patch è una rappresentazione di un set di modifiche, in cui ogni voce descrive una modifica (o un test) da effettuare. Nel caso della patch JSON, le "entità" sono nodi in un documento, con le descrizioni delle operazioni da eseguire su ciascun nodo.

Quindi, nella specifica del documento patch, definirai in che modo la rappresentazione codifica le identità da modificare, quali operazioni di modifica sono consentite, come vengono specificati gli argomenti e così via.

Una cosa da tenere a mente con più entità: RFC 5789 è molto chiaro che la semantica di PATCH è tutto o niente

The server MUST apply the entire set of changes atomically and never provide (e.g., in response to a GET during this operation) a partially modified representation. If the entire patch document cannot be successfully applied, then the server MUST NOT apply any of the changes.

Se succede qualcosa di sfortunato o costoso a causa di una patch parzialmente applicata, la responsabilità dell'errore risiede chiaramente nel server .

Ciò che normalmente si intende è che una patch dovrebbe cambiare solo entità che si trovano all'interno dello stesso limite di coerenza (ad esempio, fanno tutti parte dello stesso database fisico, quindi il server può inserire tutte le modifiche in una transazione; oppure fanno tutti parte di un singolo documento, quindi il server può modificare una copia locale del documento e quindi sostituire l'originale).

Se il server non può garantire quei vincoli di coerenza, non dovrebbe supportare il metodo PATCH.

score 0 · Answer 2

La tua struttura funziona e tutto ciò che è richiesto a PATCH deve essere idempotente: devi bloccare tutte le risorse, possibilmente un id alla volta. Anche questo potrebbe richiedere che tu raccolga e deduplichi prima tutti gli elementi dell'array, nel caso in cui un id venga specificato due volte.

Quando fai tutto questo, patchare una risorsa o più di una è essenzialmente la stessa cosa. In realtà è possibile verificare se il payload è una matrice di dizionari o un dizionario, e se quest'ultimo lo trasforma in un array di un dizionario, quindi procedere.

Per risparmiare spazio (non è una buona pratica visto che stai aggiungendo complessità) puoi intuire il significato dei campi mancanti:

op, ma percorso e valore sono presenti: questo è un aggiornamento / aggiunta
op e mancano entrambi i valori: si tratta di una rimozione del campo

Potresti anche permettere che l'id sia una matrice, il che significa che un'operazione deve essere ripetuta su diverse risorse.

Il problema sta nel gestire errori ed eccezioni. Cosa fai se la patch one fallisce? Ti avvolgere l'intera operazione all'interno di una transazione e rollback? Segnalate una serie di codici di ritorno?

200       (nothing returned) All patches OK

500       { 200: [ { 17: "OK", 29: "OK", 35: "OK" ], 500: [ { 22: "No such field" } ] }