API RESTful: terminologia per modalità / tipi di aggiornamento

Question

API RESTful: terminologia per modalità / tipi di aggiornamento

#1 da (3 voti)
#2 da (2 voti)
#3 da (1 voti)

0

Quando si progetta un'API RESTful, fornire una specifica per l'aggiornamento di un'entità costringe il progettista a prendere alcune decisioni su come si comporterà l'aggiornamento (una modalità di aggiornamento o un tipo). Ecco alcune delle modalità a cui posso pensare:

Se il corpo dell'aggiornamento contiene valori nulli, ignorarli e aggiornare solo i valori con valori non nulli. (Questo è il comportamento più comune, e penso che questo sia chiamato Delta .)
Se il corpo dell'aggiornamento contiene valori nulli, sostituire i valori esistenti con questi valori nulli. (Meno comune nella mia esperienza, penso che in un posto in cui ho lavorato l'hanno definito un Overlay ... è tipico?)
Aggiorna solo i valori attualmente nulli e non null nel corpo dell'aggiornamento. (Non sono sicuro di aver mai visto questo modulo, ma teoricamente potrebbe esserci un uso.)

Fondamentalmente, la mia domanda è, Esiste una terminologia generalmente utilizzata in REST (o anche una progettazione software in generale) per questi concetti?

Quali sono i diversi comportamenti di aggiornamento generalmente chiamati? (Tipo, Modalità, qualcos'altro?)

Questi tipi / modi diversi hanno nomi tipicamente usati?

Ci sono tipi / modalità che non ho elencato?

rest terminology naming-standards update

posta James Dunn 14.02.2018 - 00:35

fonte

3 risposte

3

Raccomando di familiarizzare con standard di patch JSON . Lo uso da solo molto nei miei software e rende molto facile gestire gli aggiornamenti delle entità in modo controllato. L'idea principale è quella di descrivere ogni modifica come operazione e inviarli all'interno di un array JSON al server in una singola richiesta.

risposta data 14.02.2018 - 22:11

fonte

2

PUT è un gioco da ragazzi: l'entità inclusa è considerata una versione modificata della risorsa memorizzata sul server di origine e il client richiede la versione memorizzata essere sostituito . (cioè interamente)

Per PATCH :

IMO non troverai nulla a riguardo nella documentazione REST e tanto meno RFC HTTP. È troppo specifico. Ogni server è fondamentalmente libero di implementare PATCH come meglio si adatta alle seguenti linee: Il metodo PATCH richiede che una serie di modifiche descritte nell'entità richiesta venga applicata alla risorsa identificata dall'URI della richiesta. Il set di modifiche è rappresentato in un formato chiamato "documento patch" identificato da un tipo di supporto .

risposta data 14.02.2018 - 14:25

fonte

Leggi altre domande sui tag rest terminology naming-standards update

Come progettare un test unitario per salvaguardare la dipendenza dallo stato interno Come risolvere efficacemente l'associazione dei dati

score 1 · Accepted Answer

Is there generally excepted terminology used in REST (or even software design in general) for these concepts?

Quando si parla di REST, oserei dire no, non esiste una terminologia del genere .

Come commenta Guillaume31, i dettagli tecnici hanno senso quando parliamo dei dettagli di implementazione ( come fare ) e guardare la domanda quest'ultima sembra più appropriata. ¹

In ogni caso, REST è agnostico per questo tipo di dettagli.

Guardando la descrizione di Wikipedia di REST non troviamo nulla su implementazioni o comportamenti attesi, ma su quelli inerenti le proprietà e i vincoli architettonici.

Dovremmo ricercare nella RFC HTTP per trovare qualcosa di più vicino a questi comportamenti, ma troveremmo il concetto idempotenza . Quale penso, non risponde alla domanda neanche.

Infine, troveremmo che per descrivere il n. 2 potremmo dire PUT e # 1,3 potremmo dire PATCH . Ma ancora non una terminologia nel senso che stai cercando.

^{1: Nella risposta originale ho detto regole aziendali poiché ritengo che la strategia per gli aggiornamenti sia condizionata dai requisiti dell'azienda. Tuttavia, è fuorviante. Quindi ho dovuto concordare con guillaume31}