Jaka jest różnica między postem a żądaniem HTTP PUT?

Tylko semantyka.

HTTP PUT mA przyjmować treść żądania, a następnie przechowywać je w zasobie identyfikowanym przez URI.

HTTP POST jest bardziej ogólny. Ma on zainicjować akcję na serwerze. Ta akcja może polegać na przechowywaniu ciała żądania w zasobie identyfikowanym przez URI lub może to być inny URI lub inna akcja.

PUT to Jak przesyłanie plików. Put to a URI wpływa dokładnie na to URI. A POST do URI może mieć jakikolwiek efekt.

Aby podać przykłady zasobów w stylu REST:

"POST / books" z kilkoma informacjami o książce może utworzyć nową książkę i odpowiedzieć nowym adresem URL identyfikującym tę książkę: "/ books / 5".

"put / books / 5" musiałby albo utworzyć nową książkę o id 5, albo zastąpić istniejącą książkę o ID 5.

W Stylu non-resource, POST może być używany do prawie wszystkiego, co ma efekt uboczny. Inną różnicą jest to, że PUT powinien być idempotentny - wielokrotne umieszczanie tych samych danych na tym samym adresie URL powinno być w porządku, gdy wiele postów może tworzyć wiele obiektów lub cokolwiek robi twoja akcja POST.

1. GET : pobiera dane z serwera. Nie powinno mieć innego efektu.
2. PUT : zastępuje docelowy zasób ładunkiem żądania. Może być używany do aktualizacji lub tworzenia nowych zasobów.
3. PATCH : podobny do PUT, ale używany do aktualizacji tylko niektórych pól w istniejącym zasobie.
4. POST : wykonuje przetwarzanie specyficzne dla zasobów na ładunku. Może być używany do różnych działań, w tym tworzenia nowego zasobu, przesyłania pliku lub przesyłanie formularza internetowego.
5. DELETE : usuwa dane z serwera.
6. TRACE : umożliwia sprawdzenie, co serwer otrzymuje. Po prostu zwraca to, co zostało wysłane.
7. OPTIONS : pozwala klientowi uzyskać informacje o metodach żądania obsługiwanych przez usługę. Odpowiednim nagłówkiem odpowiedzi jest Allow z obsługiwanymi metodami. Używany również w CORS jako żądanie inspekcji wstępnej, aby poinformować serwer o rzeczywistej metodzie żądania i zapytać o niestandardowe nagłówki.
8. HEAD : zwraca tylko nagłówki odpowiedzi.
9. CONNECT : używany przez przeglądarkę, gdy wie, że rozmawia z proxy, a ostateczny URI zaczyna się od https://. Intencją CONNECT jest umożliwienie end-to-end szyfrowanej sesji TLS, więc dane są nieczytelne dla proxy.

PUT jest rozumiany jako metoda "wgrywania" rzeczy do określonego URI lub nadpisywania tego, co jest już w tym URI.

POST jest natomiast sposobem przekazywania danych związanych z danym URI.

Zobacz HTTP RFC

Z tego co wiem, PUT służy głównie do aktualizacji rekordów.

1. POST-aby utworzyć dokument lub inny zasób

2. PUT-aby zaktualizować utworzony dokument lub inny zasób.

Ale żeby było jasne, zwykle 'zastępuje' istniejący rekord, jeśli tam jest i tworzy, jeśli go nie ma..

Inni już opublikowali doskonałe odpowiedzi, chciałem tylko dodać, że w większości języków, frameworków i przypadków użycia będziesz miał do czynienia z postem znacznie, znacznie częściej niż umieścić. Do punktu, gdzie umieścić, usunąć, itp. są w zasadzie pytania ciekawostki.

Zobacz: http://zacharyvoase.com/2009/07/03/http-post-put-diff/

Ostatnio denerwuje mnie popularne błędne przekonanie twórców stron internetowych, że POST jest używany do tworzenia zasobu, a PUT jest używany do aktualizacji/zmiany.

Jeśli spojrzysz na stronę 55 RFC 2616 ("Hypertext Transfer Protocol-HTTP/1.1"), sekcja 9.6 ("PUT"), zobaczysz do czego właściwie służy PUT:

Metoda PUT wymaga, aby zamknięty podmiot był przechowywane pod dostarczonym żądaniem-URI.

Jest też przydatny akapit wyjaśniający różnicę między postem a PUT:

Zasadnicza różnica między żądaniami POST I PUT znajduje odzwierciedlenie w innym znaczeniu Request-URI. URI w żądaniu POST identyfikuje zasób, który będzie obsługiwał zamknięty podmiot. Zasób ten może być procesem akceptującym dane, bramą do innego protokołu lub oddzielnym podmiotem akceptującym adnotacje. W natomiast URI w żądaniu PUT identyfikuje podmiot dołączony do żądania – agent użytkownika wie, jaki URI jest przeznaczony, a serwer nie może próbować zastosować żądania do innego zasobu.

Nie wspomina o różnicy między aktualizacją/tworzeniem, ponieważ nie o to chodzi. Chodzi o różnicę między tym:

obj.set_attribute(value) # A POST request.

I to:

obj.attribute = value # A PUT request.

POST jest uważany za coś z metody typu fabrycznego. Dołączasz do niego dane, aby stworzyć to, co chcesz, a cokolwiek jest po drugiej stronie, wie, co z tym zrobić. PUT jest używany do aktualizacji istniejących danych pod danym adresem URL lub do tworzenia czegoś nowego, gdy wiesz, jaki będzie URI i już nie istnieje(w przeciwieństwie do Postu, który utworzy coś i zwróci do niego adres URL, jeśli to konieczne).

Definiowanie operacji pod kątem metod HTTP

Protokół HTTP definiuje szereg metod, które przypisują znaczenie semantyczne żądaniu. Najczęściej stosowanymi metodami HTTP używanymi przez większość interfejsów API RESTful web są:

GET pobiera reprezentację zasobu o podanym URI. Treść wiadomości odpowiedzi zawiera szczegóły żądanego zasobu.

POST tworzy nowy zasób o podanym URI. Ciało komunikat request zawiera szczegóły nowego zasobu. Zauważ, że POST może być również używany do uruchamiania operacji, które w rzeczywistości nie tworzą zasobów.

PUT tworzy lub zastępuje zasób na podanym URI. Treść komunikatu żądania określa zasób, który ma zostać utworzony lub zaktualizowany.

PATCH wykonuje częściową aktualizację zasobu. Treść żądania określa zestaw zmian, które mają być zastosowane do zasobu.

DELETE usuwa zasób na podanym URI.

Efekt konkretnego żądania powinien zależeć od tego, czy zasób jest zbiorem, czy pojedynczym elementem. Poniższa tabela podsumowuje wspólne konwencje przyjęte przez większość implementacji RESTful na przykładzie e-commerce. Nie wszystkie z tych żądań mogą być realizowane-zależy to od konkretnego scenariusz.

Różnice między POST, PUT i PATCH mogą być mylące.

A Post request tworzy zasób. Serwer przypisuje URI dla nowego zasobu i zwraca go Klientowi. W modelu REST, często stosujesz żądania POST do kolekcji. Nowy zasób jest dodawany do kolekcji. Żądanie POST może być również wykorzystane do przesłania danych do przetworzenia do istniejącego zasobu, bez tworzenia nowego zasobu.

A Put request tworzy zasób lub aktualizuje istniejący zasób. Klient określa URI dla zasobu. Treść żądania zawiera pełną reprezentację zasobu. Jeśli zasób z tym URI już istnieje, jest zastępowany. W przeciwnym razie, a nowy zasób jest tworzony, jeśli serwer obsługuje to. Zapytania PUT są najczęściej stosowane do zasobów, które są indywidualnymi przedmiotami, takimi jak konkretny klient, a nie kolekcjami. Serwer może obsługiwać aktualizacje, ale nie tworzenie przez PUT. To, czy wspierać tworzenie poprzez PUT, zależy od tego, czy klient może w znaczący sposób przypisać URI do zasobu, zanim on istnieje. Jeśli nie, użyj POST do tworzenia zasobów i umieść lub łat do aktualizacji.

A PATCH request wykonuje częściowa aktualizacja do istniejącego zasobu. Klient określa URI dla zasobu. Treść żądania określa zestaw zmian, które mają być zastosowane do zasobu. Może to być bardziej efektywne niż użycie PUT, ponieważ klient wysyła tylko zmiany, a nie całą reprezentację zasobu. Technicznie PATCH może również utworzyć nowy zasób (określając zestaw aktualizacji do zasobu "null"), jeśli serwer to obsługuje.

Żądania PUT muszą być idempotentne. Jeśli klient złoży ten sam PUT żądanie wielokrotne, wyniki powinny być zawsze takie same (ten sam zasób zostanie zmodyfikowany z tymi samymi wartościami). Żądania postów i poprawek nie są gwarantowane jako idempotentne.

Powinno być dość proste, kiedy używać jednego lub drugiego, ale złożone słowa są źródłem nieporozumień dla wielu z nas.

Kiedy ich używać:

• Użyj PUT, gdy chcesz zmodyfikować pojedynczy zasób, który jest już częścią kolekcji zasobów. PUT zastępuje zasób w całości. Przykład: PUT /resources/:resourceId

  Uwaga boczna: Użyj PATCH, Jeśli chcesz zaktualizować część zasobu.

• użycie POST gdy chcesz dodać zasób potomny w kolekcji zasobów.
  Przykład: POST => /resources

Ogólnie:

• ogólnie, w praktyce, Zawsze używaj PUT dla operacji UPDATE .
• Zawsze używaj POST dla twórz operacje.

Przykład:

GET /firma / raporty => Pobierz wszystkie raporty
GET /firma / raporty / {id} => Uzyskaj informacje o raporcie oznaczone "id"
POST /firma / raporty => Utwórz nowy raport
PUT /firma / raporty / {id} => Zaktualizuj informacje o raporcie oznaczone "id"
PATCH /firma / raporty / {id} => zaktualizuj część informacji raportu oznaczoną "id"
DELETE /firma / raporty / {id} => Usuń raport przez " id "

Różnica między POST I PUT polega na tym, że PUT jest idempotentny, co oznacza, że wielokrotne wywołanie tego samego żądania PUT zawsze przyniesie ten sam wynik(nie jest to efekt uboczny), podczas gdy z drugiej strony wielokrotne wywołanie żądania POST może mieć (dodatkowe) skutki uboczne wielokrotnego tworzenia tego samego zasobu.

GET : żądania za pomocą GET pobierają tylko dane, to znaczy żądają reprezentacji określonego zasobu

POST : wysyła dane do serwera aby utworzyć zasób. Typ treści żądania jest wskazywany przez nagłówek Content-Type. Często powoduje zmianę stanu lub skutki uboczne na serwerze

PUT : tworzy nowy zasób lub zastępuje reprezentację zasobu docelowego za pomocą request payload

PATCH : jest on używany do stosowania częściowych modyfikacji do zasobu

DELETE : usuwa podany zasób

TRACE : wykonuje test pętli zwrotnej wiadomości wzdłuż ścieżki do celu źródło, dostarczające użyteczny mechanizm debugowania

OPTIONS : jest on używany do opisania opcji komunikacji dla zasobu docelowego, klient może określić adres URL dla metody OPTIONS lub gwiazdkę ( * ), aby odnieść się do całego serwera.

HEAD : żąda odpowiedzi identycznej z żądaniem GET, ale bez ciała odpowiedzi

CONNECT : ustanawia tunel do serwera identyfikowanego przez zasób docelowy, może być używany do uzyskania dostępu do stron internetowych, które używają SSL (HTTPS)

REST-ful usage

POST jest używany do tworzenia nowego zasobu, a następnie zwraca zasób URI

EX 
      REQUEST : POST ..../books
        {
        "book":"booName",
        "author":"authorName"
        }

To wywołanie może utworzyć nową księgę i zwrócić tę księgę URI

Response ...THE-NEW-RESOURCE-URI/books/5

PUT jest używany do zastąpienia zasobu, jeśli ten zasób istnieje, to po prostu go zaktualizuj, ale jeśli ten zasób nie istnieje, utwórz go,

REQUEST : PUT ..../books/5
{
"book":"booName",
"author":"authorName"
}

Z PUT znamy identyfikator zasobu, ale POST zwróci nowy identyfikator zasobu

Non REST-ful usage

POST jest używany do inicjowania akcji po stronie serwera, ta akcja może lub nie musi tworzyć zasobu, ale ta akcja będzie miała wpływ po stronie zawsze zmieni coś na serwerze

PUT jest używany do umieszczania lub zastępowania dosłownej treści pod określonym adresem URL

Inne różnice w stylach REST-ful i non-REST-ful

POST nie jest operacją Idempotentną: spowoduje pewne zmiany, jeśli zostanie wykonana wielokrotnie z ta sama Prośba.

PUT jest operacją Idempotentną: nie będzie miała żadnych skutków ubocznych, jeśli zostanie wykonana wiele razy z tym samym żądaniem.

W prostych słowach można powiedzieć:

1.HTTP Get: służy do uzyskania jednego lub więcej elementów

2.HTTP Post:służy do tworzenia elementu

3.HTTP Put: służy do aktualizacji elementu

4.Patch HTTP:służy do częściowej aktualizacji elementu

5.HTTP Delete:służy do usuwania elementu

Warto wspomnieć, że POST jest przedmiotem częstych ataków Cross-Site Request Forgery (CSRF) , podczas gdyPUT nie jest. {20]}

Poniższe CSRF są niemożliwe z PUT kiedy ofiara odwiedza attackersite.com.

Efekt ataku jest taki, że ofiara nieumyślnie usuwa użytkownika tylko dlatego, że (ofiara) była zalogowana jako admin na target.site.com, przed wizytą attackersite.com}:

Złośliwy kod na attackersite.com:

Przypadek 1: zwykłe żądanie. zapisywane target.site.com Pliki cookie są automatycznie wysyłane przez przeglądarkę: (Uwaga: Obsługa PUT tylko w punkcie końcowym jest bezpieczniejsza, ponieważ nie jest obsługiwaną wartością atrybutu <form>)

<!--deletes user with id 5-->
<form id="myform" method="post" action="http://target.site.com/deleteUser" >
    <input type="hidden" name="userId" value="5">
</form>
<script>document.createElement('form').submit.call(document.getElementById('myform'));</script>

Przypadek 2: XHR request. zapisywane target.site.com Pliki cookie będą automatycznie wysyłane przez przeglądarkę: (Uwaga: Obsługa PUT tylko w punkcie końcowym jest bezpieczniejsza, ponieważ próba wysłania PUT wywoła żądanie inspekcji wstępnej, którego odpowiedź w tym celu należy kliknąć na link "Pokaż Dane" i kliknąć na link "Pokaż dane".]}

//deletes user with id 5
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target.site.com/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);

MDN Ref : [..]W przeciwieństwie do " prostych żądań "(omówionych powyżej), --[[ oznacza: POST/GET/HEAD ]]--, dla żądań" preflighted " przeglądarka najpierw wysyła żądanie HTTP przy użyciu metody OPTIONS [..]

Kors w akcji : [..]Niektóre typy żądań, takie jak DELETE lub PUT, muszą pójść o krok dalej i poprosić o pozwolenie serwera przed złożeniem rzeczywistego żądania[..] co się nazywa wniosek o przeprowadzenie inspekcji wstępnej[..]

Właściwie nie ma żadnej różnicy poza ich tytułem. Istnieje podstawowa różnica między GET a innymi. Za pomocą metody"GET" -Request wysyłane są dane w wierszu url-address-line, które są najpierw oddzielone znakiem zapytania, a następnie znakiem&.

Ale z metodą"POST" -request, nie możesz przekazać danych przez url, ale musisz przekazać dane jako obiekt w tzw. "ciele" żądania. Po stronie serwera, musisz wtedy odczytać treść otrzymana treść w celu uzyskania wysłanych danych. Ale po drugiej stronie nie ma możliwości wysyłania treści w ciele, gdy wysyłasz zapytanie "GET".

Twierdzenie, że " GET "jest tylko do pobierania danych, a "POST" jest do wysyłania danych, jest absolutnie błędne. Nikt nie może uniemożliwić tworzenia nowej zawartości, usuwania istniejącej zawartości, edytowania istniejącej zawartości lub robienia czegokolwiek w backendzie, na podstawie danych, które są wysyłane przez żądanie " GET "lub przez żądanie" POST". I nikt nie może zapobiec możesz kodować backend w taki sposób, że z żądaniem"POST", Klient prosi o pewne dane.

Z żądaniem, bez względu na to, jakiej metody używasz, wywołujesz adres URL i wysyłasz lub nie wysyłasz pewnych danych, które chcesz przekazać serwerowi, aby rozpatrzyć twoje żądanie, a następnie klient otrzymuje odpowiedź z serwera. Dane mogą zawierać wszystko, co chcesz wysłać, backend może robić z danymi, co chce, a odpowiedź może zawierać wszelkie informacje, które chcesz tam umieścić.

Istnieją tylko te dwie podstawowe metody. GET and POST. Ale to ich struktura sprawia, że są różne, a nie to, co kodujesz w backendzie. W backendzie możesz kodować, co chcesz, z otrzymanymi danymi. Ale z żądaniem "POST"musisz wysłać / pobrać dane w treści, a nie w linii adresu url, a z żądaniem "GET", musisz wysłać / pobrać dane w linii adresu url, a nie w treści. To wszystko.

Wszystkie inne metody, takie jak "PUT", "DELETE" i tak dalej, mają taką samą strukturę jak "POST".

Metoda POST jest używana głównie, jeśli chcesz ukryć zawartość, ponieważ cokolwiek napiszesz w linii adresu url, zostanie to zapisane w pamięci podręcznej, a metoda GET jest taka sama jak zapisanie linii adresu url z danymi. Więc jeśli chcesz wysłać poufne dane, które nie zawsze muszą być nazwą użytkownika i hasłem, ale na przykład niektóre identyfikatory lub hashe, które nie chcą być wyświetlane w url-address-line, następnie należy użyć metody POST.

Również długość linii adresów URL jest ograniczona do 1024 symboli, podczas gdy metoda "POST" nie jest ograniczona. Więc jeśli masz większą ilość danych, możesz nie być w stanie wysłać go z żądaniem GET, ale musisz użyć POST-Request. Jest to również kolejny plus dla POST-request.

Ale radzenie sobie z żądaniem GET jest o wiele łatwiejsze, gdy nie masz skomplikowanego tekstu do wysłania. Inaczej, a to jest kolejnym plusem metody POST jest to, że za pomocą metody GET musisz zakodować tekst url, aby móc wysyłać niektóre symbole w tekście lub nawet spacje. Ale dzięki metodzie POST nie masz żadnych ograniczeń, a Twoja treść nie musi być zmieniana ani manipulowana w żaden sposób.

Zarówno PUT, jak i POST są metodami Spoczynkowymi .

PUT - jeśli dwukrotnie wykonamy to samo żądanie używając PUT używając tych samych parametrów, drugie żądanie nie będzie miało żadnego efektu. Dlatego PUT jest zwykle używany do scenariusza aktualizacji,wywołanie Update więcej niż jeden raz z tymi samymi parametrami nie robi nic więcej niż początkowe wywołanie, dlatego PUT jest idempotentne.

POST nie jest idempotentny , na przykład Create utworzy dwa oddzielne wpisy do celu, dlatego nie jest idempotent so CREATE jest szeroko stosowany w poście.

Wykonywanie tego samego wywołania przy użyciu posta z tymi samymi parametrami za każdym razem spowoduje dwie różne rzeczy, dlatego POST jest powszechnie używany do scenariusza tworzenia

Metody żądania GET, PUT I DELETE to operacje CRUD (create, read, update and delete)-czyli operacje zarządzania danymi-na stanie zasobu docelowego (identyfikowanego przez URI żądania):

• GET powinien odczytać Stan zasobu docelowego;
• PUT powinien utworzyć lub zaktualizować Stan zasobu docelowego;
• Usuń powinien usunąć Stan zasobu docelowego.

The request method POST to inna bestia. Nie powinien tworzyć stanu zasobu docelowego, takiego jak PUT, ponieważ jest to operacja procesu z celem wyższego poziomu niż CRUD (por. RFC 7231, § 4.3.3). Proces Może utworzyć zasób, ale różni się od zasobu docelowego, w przeciwnym razie należy użyć metody żądania celu niższego poziomu PUT, więc nawet w tym przypadku, który nie czyni go operacją CRUD.

Różnica między operacjami CRUD (GET, PUT and DELETE w http) i operacje non-CRUD (POST w HTTP) to różnica między abstrakcyjnymi typami danych i obiektami , którą Alan Kay podkreślał w większości swoich wykładów i pracy z ACMWczesna historia Smalltalk:

Od Simuli dostałem to, że można teraz zamienić wiązania i zadania na cele. Ostatnią rzeczą, którą chciałbyś, aby jakikolwiek programista zrobił, jest bałagan ze stanem wewnętrznym, nawet jeśli jest przedstawiony w przenośni. Zamiast tego obiekty powinny być przedstawione jako miejsca zachowań wyższego poziomu, bardziej odpowiednie do wykorzystania jako elementy dynamiczne.

[ ... ] szkoda, że wiele z tego, co dziś nazywa się "programowaniem obiektowym", to po prostu programowanie w starym stylu z bardziej fantazyjnymi konstrukcjami. Wiele programów jest ładowanych operacjami "w stylu przypisania" wykonywanymi teraz przez droższe dołączone procedury.

[...] deklaracje zadań-nawet abstrakcyjne-wyrażają bardzo niskie cele, a Więcej z nich będzie potrzebnych, aby cokolwiek załatwione. [...] Innym sposobem myślenia o tym wszystkim jest: chociaż późne wiązanie automatycznych alokacji pamięci nie robi niczego, czego programista nie może zrobić, jego obecność prowadzi zarówno do prostszego, jak i bardziej wydajnego kodu. OOP jest późno wiążącą strategią dla wielu rzeczy i wszystkie one razem powstrzymują kruchość i eksplozję wielkości znacznie dłużej niż starsze metodologie.