Qual è la differenza principale tra la richiesta PATCH e PUT?


187

Sto usando una PUTrichiesta nella mia applicazione Rails. Ora, un nuovo verbo HTTP,PATCH è stato implementato dai browser. Quindi, voglio sapere qual è la differenza principale tra PATCHe le PUTrichieste e quando dovremmo usare l'una o l'altra.

Risposte:


139

I verbi HTTP sono probabilmente una delle cose più criptiche sul protocollo HTTP. Esistono e ce ne sono molti, ma perché esistono?

Rails sembra voler supportare molti verbi e aggiungere alcuni verbi che non sono supportati nativamente dai browser web.

Ecco un elenco esaustivo di verbi http: http://annevankesteren.nl/2007/10/http-methods

C'è la patch HTTP dalla RFC ufficiale: https://datatracker.ietf.org/doc/rfc5789/?include_text=1

Il metodo PATCH richiede l'applicazione di una serie di modifiche descritte nell'entità richiesta alla risorsa identificata dall'URI della richiesta. L'insieme delle modifiche è rappresentato in un formato chiamato "documento patch" identificato da un tipo di supporto. Se l'URI della richiesta non punta a una risorsa esistente, il server PUO ' creare una nuova risorsa, a seconda del tipo di documento patch (se può modificare logicamente una risorsa nulla) e delle autorizzazioni, ecc.

La differenza tra le richieste PUT e PATCH si riflette nel modo in cui il server elabora l'entità inclusa per modificare la risorsa identificata dall'URI di richiesta. In una richiesta PUT , l'entità inclusa viene considerata una versione modificata della risorsa memorizzata sul server di origine e il client richiede la sostituzione della versione archiviata. Con PATCH , tuttavia, l'entità inclusa contiene una serie di istruzioni che descrivono come modificare una risorsa attualmente residente sul server di origine per produrre una nuova versione. Il metodo PATCH influenza la risorsa identificata dall'URI di richiesta e anche MAGGIOavere effetti collaterali su altre risorse; cioè, nuove risorse possono essere create, o esistenti, modificate, mediante l'applicazione di un PATCH .

Per quanto ne so, il verbo PATCH non viene utilizzato come nelle applicazioni rails ... A quanto ho capito, il verbo patch RFC dovrebbe essere usato per inviare istruzioni patch come quando si fa una differenza tra due file. Invece di inviare nuovamente l'intera entità, si invia una patch che potrebbe essere molto più piccola rispetto al rinvio dell'intera entità.

Immagina di voler modificare un file enorme. Si modificano 3 righe. Invece di rispedire il file, devi solo inviare il diff. Tra i lati positivi, l'invio di una richiesta di patch potrebbe essere utilizzato per unire i file in modo asincrono. Un sistema di controllo versione potrebbe potenzialmente utilizzare il verbo PATCH per aggiornare il codice in remoto.

Un altro possibile caso d'uso è in qualche modo correlato ai database NoSQL, è possibile archiviare documenti. Supponiamo che utilizziamo una struttura JSON per inviare avanti e indietro i dati dal server al client. Se volessimo eliminare un campo, potremmo usare una sintassi simile a quella in mongodb per $ unset . In realtà, il metodo usato in mongodb per aggiornare i documenti potrebbe essere probabilmente usato per gestire patch json.

Prendendo questo esempio:

db.products.update(
   { sku: "unknown" },
   { $unset: { quantity: "", instock: "" } }
)

Potremmo avere qualcosa del genere:

PATCH /products?sku=unknown
{ "$unset": { "quantity": "", "instock": "" } }

Infine, ma non meno importante, le persone possono dire quello che vogliono sui verbi HTTP. C'è solo una verità, e la verità è nelle RFC.


1
È importante notare che RFC 5789 è ancora in fase di proposta e non è stato ufficialmente accettato ed è attualmente contrassegnato come "irrata esiste". Questa "best practice" è molto dibattuta e tecnicamente PATCH non fa ancora parte dello standard HTTP. L'unica verità qui è che, poiché la RFC non è accettata, non dovresti farlo.
fishpen0

3
Anche se è ancora in proposta, non significa che non dovrebbe essere usato. Se così fosse, non saremmo in grado di utilizzare websocket e molti altri RFF che sono ancora in proposta ... L'implementazione della proposta è 100 volte migliore rispetto all'implementazione di qualcosa di completamente personalizzato che nessun altro implementa.
Loïc Faure-Lacroix,

BS. Non è "in proposta", e fa parte dello standard HTTP (lo standard, RFC 7231 delega a un registro IANA per i metodi e PATCH è elencato lì).
Julian Reschke,

@JulianReschke se leggi la seconda riga di questo RFC, vedrai che è ancora contrassegnato come PROPOSED STANDARD . Quindi no, il metodo patch è ancora in proposta. L'RFC è qui a proposito. tools.ietf.org/html/rfc5789 e rfc7231 è anche PROPOSTO STANDARD . Se ad esempio guardi la RFC821, è contrassegnata come INTERNET STANDARD
Loïc Faure-Lacroix il

1
@JulianReschke en.wikipedia.org/wiki/Internet_Standard#Proposed_Standard ... Non è la mia parola. Uno standard proposto non significa che non puoi implementarlo bene come ho spiegato sopra. Non significa che non sia abbastanza stabile da implementare ... ma è ancora in proposta a meno che non sia contrassegnato come Internet Standard ... Non sono sicuro di come stai discutendo su questo. Si chiama "proposta standard" non può significare nient'altro che una proposta. Se vuoi sostenere che è possibile utilizzare uno standard proposto. È esattamente quello che ho scritto.
Loïc Faure-Lacroix

104

Ho trascorso un paio d'ore con Google e ho trovato la risposta qui

PUT => Se l'utente può aggiornare tutto o solo una parte del record , usa PUT (l'utente controlla ciò che viene aggiornato)

PUT /users/123/email
new.email@example.org

PATCH => Se l'utente può aggiornare solo un record parziale , dire solo un indirizzo e-mail (l'applicazione controlla cosa può essere aggiornato), utilizzare PATCH.

PATCH /users/123
[description of changes]

Perché Patch

PUTil metodo richiede maggiore larghezza di banda o gestisce risorse complete anziché parziali. Così è PATCHstato introdotto per ridurre la larghezza di banda.

Spiegazione su PATCH

PATCH è un metodo non sicuro, né idempotente e che consente aggiornamenti e effetti collaterali completi e parziali su altre risorse.

PATCH è un metodo in cui l'entità racchiusa contiene una serie di istruzioni che descrivono come modificare una risorsa attualmente residente sul server di origine per produrre una nuova versione.

PATCH /users/123
[
  { "op": "replace", "path": "/email", "value": "new.email@example.org" }
]

Qui maggiori informazioni su put e patch


7
Perché questo PATCH non è sicuro?
Bishisht Bhatta,

1
PATCHtra POST, PUTecc. non è "sicuro", perché modifica i tuoi dati (ha effetti collaterali). Rispetto a GET, OPTIONSecc. (Metodi sicuri) in cui è possibile chiamare gli endpoint più volte senza effetti collaterali.
emix

1
PATCH NON è stato introdotto per salvare solo la banda. Come afferma RFC 5789:> "È necessario un nuovo metodo per migliorare l'interoperabilità e prevenire errori." In un ambiente multi parallelo con solo PUT che includono il resto del payload aumenterebbe il rischio di modifica di altri attributi della risorsa. PATCH risolve questo problema.
Tomasz Nazar,

43

metti
se voglio cambiare il mio firstnome quindi invia la richiesta put per l'aggiornamento

{ "first": "Nazmul", "last": "hasan" } 

ma qui c'è un problema è la putrichiesta che quando voglio inviare la putrichiesta devo inviare tutti e due i parametri che è firste last
quindi è obbligatorio inviare di nuovo tutto il valore

patch :
patchrichiesta dice. invia solo dataquello che desideri updatee non influirà o modificherà altri dati.
quindi non è necessario inviare nuovamente tutto il valore. voglio solo aggiornare il mio nome, quindi devo inviare solo il firstnome per l'aggiornamento.


13

Ecco la differenza tra i metodi POST, PUT e PATCH di un protocollo HTTP.

INVIARE

Un metodo HTTP.POST crea sempre una nuova risorsa sul server. È una richiesta non idempotente, ovvero se l'utente risponde alle stesse richieste 2 volte creerebbe un'altra nuova risorsa se non ci sono vincoli.

Il metodo http post è come una query INSERT in SQL che crea sempre un nuovo record nel database.

Esempio: utilizzare il metodo POST per salvare nuovi utenti, ordini, ecc. Dove il server back-end decide l'id della risorsa per la nuova risorsa.

METTERE

Nel metodo HTTP.PUT la risorsa viene prima identificata dall'URL e, se esiste, viene aggiornata altrimenti viene creata una nuova risorsa. Quando la risorsa di destinazione esiste, sovrascrive quella risorsa con un nuovo corpo completo. Questo è il metodo HTTP.PUT utilizzato per CREARE o AGGIORNARE una risorsa.

Il metodo http put è come una query MERGE in SQL che inserisce o aggiorna un record a seconda dell'esistenza del record specificato.

La richiesta PUT è idempotente, cioè se si rispondono due volte alle stesse richieste si aggiorna la registrazione esistente (nessun nuovo record creato). Nel metodo PUT l'ID risorsa viene deciso dal client e fornito nell'URL della richiesta.

Esempio: utilizzare il metodo PUT per aggiornare l'utente o l'ordine esistenti.

PATCH

Un metodo HTTP.PATCH viene utilizzato per modifiche parziali a una risorsa, ad esempio aggiornamenti delta.

Il metodo patch http è come una query UPDATE in SQL che imposta o aggiorna solo le colonne selezionate e non l'intera riga.

Esempio: è possibile utilizzare il metodo PATCH per aggiornare lo stato dell'ordine.

PATCH / api / users / 40450236 / order / 10234557

Corpo della richiesta: {status: 'Delivered'}


Questa è la peggiore spiegazione che chiunque possa mai leggere su put e patch. E poi, dopo aver già pubblicato tante buone risposte, cosa ti fa pensare che la tua risposta sia diversa qui?
CodeHunter,

3

Esistono limitazioni in PUT su PATCH durante gli aggiornamenti. L'uso di PUT ci richiede di specificare tutti gli attributi anche se vogliamo cambiare solo un attributo. Ma se utilizziamo il metodo PATCH possiamo aggiornare solo i campi di cui abbiamo bisogno e non è necessario menzionare tutti i campi. PATCH non ci consente di modificare un valore in un array o di rimuovere un attributo o una voce di array.


1

I metodi PUT e PATCH sono simili in natura, ma c'è una differenza fondamentale.

PUT - nella richiesta PUT , l'entità inclusa sarebbe considerata la versione modificata di una risorsa che risiede sul server e sarebbe sostituita da questa entità modificata.

PATCH : nella richiesta PATCH , l'entità racchiusa contiene l'insieme di istruzioni su come l'entità che risiede sul server verrebbe modificata per produrre una versione più recente.


1

Secondo i termini HTTP, la PUTrichiesta è proprio come un'istruzione di aggiornamento del database. PUT- viene utilizzato per modificare la risorsa esistente (precedentemente POSTATO). D'altra parte, la PATCHrichiesta viene utilizzata per aggiornare una parte della risorsa esistente.

Per esempio:

Dettagli cliente:

// This is just a example.

firstName = "James";
lastName = "Anderson";
email = "email@domain.com";
phoneNumber = "+92 1234567890";
//..

Quando vogliamo aggiornare l'intero record? dobbiamo usare Http PUT verbper quello.

ad esempio:

// Customer Details Updated.

firstName = "James++++";
lastName = "Anderson++++";
email = "email@Updated.com";
phoneNumber = "+92 0987654321";
//..

D'altra parte, se vogliamo aggiornare solo la parte del record, non l'intero record, andiamo avanti Http PATCH verb. ad esempio:

   // Only Customer firstName and lastName is Updated.

    firstName = "Updated FirstName";
    lastName = "Updated LastName";
   //..

PUT VS POST:

Quando si utilizza la PUTrichiesta, è necessario inviare tutti i parametri come firstName, lastName, email, phoneNumber Where as In patchrequest invia solo i parametri che vogliamo aggiornare e non influenzerà o modificherà altri dati.

Per maggiori dettagli, visitare: https://fullstack-developer.academy/restful-api-design-post-vs-put-vs-patch/


0

I metodi Put e Patch sono simili. Ma nei binari ha un metodo diverso Se vogliamo aggiornare / sostituire l'intero record, allora dobbiamo usare il metodo Put. Se vogliamo aggiornare un particolare record, utilizzare il metodo Patch.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.