Jaka jest główna różnica między PATCH a żądaniem PUT?


187

Korzystam z PUTżądania w mojej aplikacji Rails. Teraz PATCHprzeglądarki zaimplementowały nowy czasownik HTTP . Tak, chcę wiedzieć, co główna różnica między PATCHi PUTwnioski są, a kiedy powinniśmy użyć jednego lub drugiego.

Odpowiedzi:


139

Czasowniki HTTP są prawdopodobnie jedną z najbardziej tajemniczych rzeczy w protokole HTTP. Istnieją i jest ich wiele, ale dlaczego istnieją?

Wydaje się, że Railsy chcą obsługiwać wiele czasowników i dodawać niektóre czasowniki, które nie są obsługiwane przez przeglądarki internetowe natywnie.

Oto wyczerpująca lista czasowników http: http://annevankesteren.nl/2007/10/http-methods

Jest łatka HTTP z oficjalnej wersji RFC: https://datatracker.ietf.org/doc/rfc5789/?include_text=1

Metoda PATCH żąda zastosowania zestawu zmian opisanych w encji żądania do zasobu określonego przez identyfikator URI żądania. Zestaw zmian jest reprezentowany w formacie zwanym „dokumentem poprawki” identyfikowanym przez typ nośnika. Jeśli identyfikator URI żądania nie wskazuje na istniejący zasób, serwer MOŻE utworzyć nowy zasób, w zależności od typu dokumentu poprawki (czy może logicznie zmodyfikować zasób zerowy) i uprawnień itp.

Różnica między żądaniami PUT i PATCH znajduje odzwierciedlenie w sposobie, w jaki serwer przetwarza encję zamkniętą w celu zmodyfikowania zasobu identyfikowanego przez identyfikator URI żądania. W żądaniu PUT załączony obiekt jest uważany za zmodyfikowaną wersję zasobu przechowywanego na serwerze źródłowym, a klient żąda zastąpienia zapisanej wersji. Jednak w PATCH dołączona jednostka zawiera zestaw instrukcji opisujących, w jaki sposób zasób obecnie przebywający na serwerze źródłowym powinien zostać zmodyfikowany, aby utworzyć nową wersję. Metoda PATCH wpływa na zasób zidentyfikowany przez identyfikator URI żądania i również MAYmieć skutki uboczne na inne zasoby; tj. nowe zasoby mogą być tworzone lub istniejące mogą być modyfikowane przez zastosowanie PATCH .

O ile mi wiadomo, czasownik PATCH nie jest używany tak jak w aplikacjach szynowych ... Jak rozumiem, czasownik łatki RFC powinien być używany do wysyłania instrukcji łaty, np. Gdy robisz różnicę między dwoma plikami. Zamiast ponownie wysyłać cały byt, wysyłasz łatkę, która może być znacznie mniejsza niż ponowne wysyłanie całego bytu.

Wyobraź sobie, że chcesz edytować ogromny plik. Edytujesz 3 linie. Zamiast odsyłać plik z powrotem, wystarczy wysłać różnicę. Z drugiej strony, wysyłanie żądania łatki może być wykorzystane do asynchronicznego scalenia plików. System kontroli wersji mógłby potencjalnie wykorzystać czasownik PATCH do zdalnej aktualizacji kodu.

Kolejny możliwy przypadek użycia jest nieco związany z bazami danych NoSQL, można przechowywać dokumenty. Powiedzmy, że używamy struktury JSON do wysyłania danych tam iz powrotem z serwera do klienta. Gdybyśmy chcieli usunąć pole, moglibyśmy użyć składni podobnej do tej w mongodb dla $ unset . W rzeczywistości metoda zastosowana w mongodb do aktualizacji dokumentów mogłaby prawdopodobnie zostać użyta do obsługi łatek Json.

Biorąc ten przykład:

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

Moglibyśmy mieć coś takiego:

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

Wreszcie, ludzie mogą powiedzieć co tylko chcą o czasownikach HTTP. Jest tylko jedna prawda, a prawda jest w RFC.


1
Należy zauważyć, że RFC 5789 jest wciąż w fazie składania wniosków i nie został oficjalnie zaakceptowany i obecnie jest oflagowany jako „Irata istnieje”. Ta „najlepsza praktyka” jest szeroko dyskutowana i technicznie PATCH nie jest jeszcze częścią standardu HTTP. Jedyną prawdą jest to, że skoro RFC jest nieakceptowany, nie powinieneś tego robić.
fishpen0

3
Nawet jeśli nadal jest w ofercie, nie oznacza to, że nie należy go używać. Gdyby tak było, nie bylibyśmy w stanie użyć websockets i wielu innych rfcs, które wciąż są w ofercie ... Implementacja propozycji jest 100 razy lepsza niż implementacja czegoś całkowicie niestandardowego, czego nikt inny nie implementuje.
Loïc Faure-Lacroix,

BS. Nie jest „w propozycji” i jest częścią standardu HTTP (standard, RFC 7231 deleguje do rejestru IANA metod, a PATCH jest tam wymieniony).
Julian Reschke,

@JulianReschke, jeśli czytasz drugą linię tego dokumentu RFC, zobaczysz, że nadal jest on oznaczony jako PROPONOWANY STANDARD . Więc nie, metoda łatki jest wciąż w ofercie. RFC jest tutaj przy okazji. tools.ietf.org/html/rfc5789, a rfc7231 jest również PROPONOWANYM STANDARDEM . Na przykład RFC821 jest oznaczony jako INTERNET STANDARD
Loïc Faure-Lacroix,

1
@JulianReschke en.wikipedia.org/wiki/Internet_Standard#Proposed_Standard ... To nie jest moje słowo. Proponowany standard nie oznacza, że ​​nie możesz go dobrze wdrożyć, jak wyjaśniłem powyżej. Nie oznacza to, że nie jest wystarczająco stabilny do wdrożenia ... ale wciąż jest w propozycji, chyba że jest oznaczony jako Internet Standard ... Nie jestem pewien, jak się o to kłócisz. Nazywa się to „proponowanym standardem”, nie może oznaczać nic innego niż propozycja. Jeśli chcesz argumentować, że można zastosować proponowany standard. To jest dokładnie to, co napisałem.
Loïc Faure-Lacroix

104

Spędziłem kilka godzin z Google i znalazłem odpowiedź tutaj

PUT => Jeśli użytkownik może zaktualizować cały lub tylko część rekordu , użyj PUT (użytkownik kontroluje, co zostanie zaktualizowane)

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

PATCH => Jeśli użytkownik może zaktualizować tylko częściowy rekord , powiedz tylko adres e-mail (aplikacja kontroluje, co można zaktualizować), użyj PATCH.

PATCH /users/123
[description of changes]

Czemu Patch

PUTmetoda wymaga większej przepustowości lub obsługuje pełne zasoby zamiast częściowego. Tak PATCHwprowadzono w celu zmniejszenia przepustowości.

Wyjaśnienie dotyczące PATCH

PATCH to metoda, która nie jest bezpieczna ani idempotentna i umożliwia pełne i częściowe aktualizacje oraz skutki uboczne dla innych zasobów.

PATCH to metoda, która zawiera encję zawierającą zestaw instrukcji opisujących, w jaki sposób zasób obecnie przebywający na serwerze źródłowym powinien zostać zmodyfikowany w celu utworzenia nowej wersji.

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

Tutaj więcej informacji o put i patch


7
Dlaczego ta PATCH nie jest bezpieczna?
Bishisht Bhatta,

1
PATCHu POST, PUTitd. nie jest „bezpieczny”, ponieważ modyfikuje danych (ma skutki uboczne). W porównaniu do GET, OPTIONSitd. (Bezpieczne metody), gdzie można zadzwonić do punktów końcowych wielokrotnie bez żadnych skutków ubocznych.
emix

1
PATCH NIE został wprowadzony wyłącznie w celu oszczędzania pasma. Jak stwierdza RFC 5789:> „Konieczna jest nowa metoda w celu poprawy interoperacyjności i zapobiegania błędom”. W środowisku wielu równoległych posiadanie tylko tych PUT, które zawierają resztę ładunku, zwiększyłoby ryzyko modyfikacji innych atrybutów zasobu. PATCH rozwiązuje taki problem.
Tomasz Nazar

43

umieścić
jeśli chcę zmienić firstnazwę następnie wysłać put wniosek o aktualizację

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

ale tutaj jest jeden problem jest putwniosek, że gdy chcę wysłać putprośbę muszę wysłać wszystkie dwa parametry, które jest firsti last
tak jest to obowiązkowe, aby wysłać ponownie wszystkie wartości

Łatka :
patchprośba mówi. wyślij tylko ten, dataktóry chcesz, updatea to nie wpłynie ani nie zmieni innych danych.
więc nie trzeba ponownie wysyłać całej wartości. chcę tylko zaktualizować swoje imię, więc muszę wysłać tylko firstnazwę do aktualizacji.


13

Oto różnica między metodami POST, PUT i PATCH protokołu HTTP.

POCZTA

Metoda HTTP.POST zawsze tworzy nowy zasób na serwerze. Jest to żądanie nie idempotentne, tzn. Jeśli użytkownik trafi dwa razy te same żądania, utworzyłby inny nowy zasób, gdyby nie było żadnych ograniczeń.

Metoda http post jest jak zapytanie INSERT w SQL, które zawsze tworzy nowy rekord w bazie danych.

Przykład: Użyj metody POST, aby zapisać nowego użytkownika, zamówienie itp., Gdzie serwer zaplecza decyduje o identyfikatorze zasobu dla nowego zasobu.

POŁOŻYĆ

W metodzie HTTP.PUT zasób jest najpierw identyfikowany na podstawie adresu URL, a jeśli istnieje, jest aktualizowany, w przeciwnym razie tworzony jest nowy zasób. Gdy zasób docelowy istnieje, zastępuje ten zasób kompletnym nowym ciałem. To jest metoda HTTP.PUT służy do TWORZENIA lub AKTUALIZACJI zasobu.

Metoda HTTP put jest jak zapytanie MERGE w SQL, które wstawia lub aktualizuje rekord w zależności od tego, czy dany rekord istnieje.

Żądanie PUT jest idempotentne, tzn. Dwukrotne naciśnięcie tego samego żądania zaktualizowałoby istniejące nagranie (nie utworzono nowego rekordu). W metodzie PUT identyfikator zasobu jest ustalany przez klienta i podawany w adresie URL żądania.

Przykład: Użyj metody PUT, aby zaktualizować istniejącego użytkownika lub zamówienie.

ŁATA

Metoda HTTP.PATCH służy do częściowych modyfikacji zasobu, tj. Aktualizacji delta.

Metoda łatania http jest jak zapytanie UPDATE w SQL, które ustawia lub aktualizuje tylko wybrane kolumny, a nie cały wiersz.

Przykład: Możesz użyć metody PATCH, aby zaktualizować status zamówienia.

PATCH / api / users / 40450236 / order / 10234557

Treść żądania: {status: „Dostarczono”}


To najgorsze wytłumaczenie, jakie ktokolwiek może przeczytać o put i patch. A poza tym, po tak wielu dobrych odpowiedziach, co sprawia, że ​​uważasz, że Twoja odpowiedź jest inna?
CodeHunter

3

Istnieją pewne ograniczenia w PUT zamiast PATCH podczas aktualizacji. Użycie PUT wymaga od nas określenia wszystkich atrybutów, nawet jeśli chcemy zmienić tylko jeden atrybut. Ale jeśli użyjemy metody PATCH, możemy zaktualizować tylko pola, których potrzebujemy i nie trzeba wspominać o wszystkich polach. PATCH nie pozwala nam modyfikować wartości w tablicy ani usuwać atrybutu lub pozycji tablicy.


1

Metody PUT i PATCH mają podobny charakter, ale istnieje zasadnicza różnica.

PUT - w żądaniu PUT dołączony byt byłby uważany za zmodyfikowaną wersję zasobu znajdującego się na serwerze i zostałby zastąpiony przez ten zmodyfikowany byt.

PATCH - w żądaniu PATCH , encja zamknięta zawiera zestaw instrukcji, w jaki sposób encja znajdująca się na serwerze zostanie zmodyfikowana w celu uzyskania nowszej wersji.


1

Zgodnie z warunkami HTTP PUTżądanie jest jak instrukcja aktualizacji bazy danych. PUT- służy do modyfikowania istniejącego zasobu (poprzednio POSTED). Z drugiej strony PATCHżądanie służy do aktualizacji części istniejącego zasobu.

Na przykład:

Szczegóły klienta:

// This is just a example.

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

Kiedy chcemy zaktualizować cały rekord? musimy do tego wykorzystać Http PUT verb.

Jak na przykład:

// Customer Details Updated.

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

Z drugiej strony, jeśli chcemy zaktualizować tylko część rekordu, a nie cały rekord, wybierz Http PATCH verb. Jak na przykład:

   // Only Customer firstName and lastName is Updated.

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

PUT VS POST:

Podczas korzystania z PUTżądania musimy wysłać wszystkie parametry, takie jak imię, nazwisko, adres e-mail, numer telefonu Gdzie jak w patchżądaniu wysyłamy tylko parametry, które chcemy zaktualizować, i nie wpłynie to ani nie zmieni innych danych.

Więcej informacji można znaleźć na stronie : https://fullstack-developer.academy/restful-api-design-post-vs-put-vs-patch/


0

Metoda Put i Patch są podobne. Ale w szynach ma inną metodę. Jeśli chcemy zaktualizować / zastąpić cały rekord, musimy użyć metody Put. Jeśli chcemy zaktualizować konkretny rekord, skorzystaj z metody Patch.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.