Jaka jest różnica między POST a PUT HTTP REQUEST?

Wydaje się, że oba przesyłają dane na serwer wewnątrz ciała, więc co je odróżnia?

PUT HTTP:

PUT umieszcza plik lub zasób pod określonym URI i dokładnie pod tym URI. Jeśli pod tym identyfikatorem URI jest już plik lub zasób, PUT zastępuje ten plik lub zasób. Jeśli nie ma tam pliku ani zasobu, PUT tworzy taki plik. PUT jest idempotentny , ale paradoksalnie odpowiedzi PUT nie są buforowane.

Lokalizacja HTTP 1.1 RFC dla PUT

POST HTTP:

POST wysyła dane do określonego URI i oczekuje, że zasób w tym URI obsłuży żądanie. Serwer WWW w tym momencie może określić, co zrobić z danymi w kontekście określonego zasobu. Metoda POST nie jest idempotentna , jednak odpowiedzi POST są buforowalne, o ile serwer ustawia odpowiednią kontrolę pamięci podręcznej i wygasa.

Oficjalna HTTP RFC określa POST jako:

• Adnotacja do istniejących zasobów;
• Publikowanie wiadomości na tablicy ogłoszeń, grupie dyskusyjnej, liście mailingowej lub podobnej grupie artykułów;
• Zapewnienie bloku danych, takiego jak wynik przesłania formularza, do procesu przetwarzania danych;
• Rozszerzanie bazy danych za pomocą operacji dołączania.

Lokalizacja HTTP 1.1 RFC dla testu POST

Różnica między POST a PUT:

Sam RFC wyjaśnia zasadniczą różnicę:

Podstawowa różnica między żądaniami POST i PUT znajduje odzwierciedlenie w innym znaczeniu URI żądania. Identyfikator URI w żądaniu POST identyfikuje zasób, który będzie obsługiwał zamknięty obiekt. Ten zasób może być procesem akceptującym dane, bramą do innego protokołu lub osobnym podmiotem, który przyjmuje adnotacje. W przeciwieństwie do tego, URI w żądaniu PUT identyfikuje encję dołączoną do żądania - agent użytkownika wie, jaki jest URI, a serwer NIE MOŻE próbować zastosować żądania do jakiegoś innego zasobu. Jeśli serwer chce zastosować żądanie do innego identyfikatora URI, MUSI wysłać odpowiedź 301 (Moved Permanently); klient użytkownika MOŻE następnie podjąć własną decyzję dotyczącą tego, czy przekierować żądanie.

Dodatkowo i nieco bardziej zwięźle, RFC 7231 Sekcja 4.3.4 Stany PUT (wyróżnienie dodane),

4.3.4 POŁOŻYĆ

Metoda PUT żąda, aby stan zasobu docelowego był createdlub replacedze stanem zdefiniowanym przez reprezentację zawartą w ładunku komunikatu żądania.

Używając właściwej metody, niepowiązanej na bok:

Jedną z zalet REST ROA w porównaniu z SOAP jest to, że podczas korzystania z HTTP REST ROA zachęca do właściwego użycia czasowników / metod HTTP. Na przykład użyjesz PUT tylko wtedy, gdy chcesz utworzyć zasób w tej właśnie lokalizacji. I nigdy nie użyłbyś GET do utworzenia lub modyfikacji zasobu.

Tylko semantyka.

HTTP PUTpowinien zaakceptować treść żądania, a następnie przechowywać go w zasobie określonym przez URI.

HTTP POSTjest bardziej ogólny. Ma zainicjować akcję na serwerze. To działanie może polegać na przechowywaniu treści żądania w zasobie określonym przez identyfikator URI, może to być inny identyfikator URI lub inna akcja.

PUT jest jak przesyłanie pliku. Wprowadzenie do identyfikatora URI wpływa dokładnie na ten identyfikator URI. POST do identyfikatora URI może mieć jakikolwiek efekt.

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

„POST / books” z dużą ilością informacji 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łoby albo utworzyć nową książkę o identyfikatorze 5, albo zastąpić istniejącą książkę ID 5.

W stylu innym niż POST można używać POST do wszystkiego, co ma efekt uboczny. Inna różnica polega na tym, że PUT powinien być idempotentny - wiele PUT tych samych danych do tego samego adresu URL powinno być w porządku, a wiele POST może tworzyć wiele obiektów lub cokolwiek to robi twoja akcja POST.

1. GET : pobiera dane z serwera. Nie powinien mieć żadnego innego efektu.
2. POST : Wysyła dane do serwera w celu utworzenia nowego obiektu. Często używany podczas przesyłania pliku lub formularza internetowego.
3. PUT : Podobne do POST, ale używane do zastąpienia istniejącej jednostki.
4. PATCH : podobny do PUT, ale używany do aktualizowania tylko niektórych pól w istniejącej jednostce.
5. DELETE : Usuwa dane z serwera.
6. ŚLEDZENIE : Zapewnia sposób na sprawdzenie, co serwer odbiera. Zwraca tylko to, co zostało wysłane.
7. OPCJE : Pozwala klientowi uzyskać informacje o metodach żądania obsługiwanych przez usługę. Odpowiednim nagłówkiem odpowiedzi jest Zezwalaj z obsługiwanymi metodami. Używany również w CORS jako żądanie wstępnego sprawdzenia w celu poinformowania serwera o rzeczywistej metodzie żądania i zapytania o niestandardowe nagłówki.
8. HEAD : Zwraca tylko nagłówki odpowiedzi.
9. CONNECT : Używany przez przeglądarkę, gdy wie, że komunikuje się z serwerem proxy, a ostateczny identyfikator URI zaczyna się od https: //. CONNECT ma na celu umożliwienie szyfrowanej sesji TLS typu end-to-end, więc dane są nieczytelne dla proxy.

PUT jest rozumiany jako metoda „przesyłania” rzeczy do określonego URI lub nadpisywania tego, co już jest w tym URI.

Z drugiej strony, POST to sposób przesyłania danych ZWIĄZANYCH z danym URI.

Zobacz RFC HTTP

O ile mi wiadomo, PUT służy głównie do aktualizacji rekordów.

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

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

Ale dla jasności w tym PUT zwykle „zastępuje” istniejący rekord, jeśli istnieje i tworzy, jeśli go nie ma.

Inni już opublikowali doskonałe odpowiedzi, chciałem tylko dodać, że z większością języków, frameworków i przypadków użycia będziesz mieć do czynienia z POST znacznie, znacznie częściej niż PUT. Do tego stopnia, że ​​PUT, DELETE itp. Są w zasadzie pytaniami 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 służy do tworzenia zasobu, a PUT służy do jego aktualizacji / zmiany.

Jeśli spojrzysz na stronę 55 RFC 2616 („Protokół przesyłania hipertekstu - HTTP / 1.1”), sekcja 9.6 („PUT”), zobaczysz, dla czego PUT jest w rzeczywistości:

Metoda PUT żąda, aby zamknięta jednostka była przechowywana pod dostarczonym URI żądania.

Jest też przydatny akapit wyjaśniający różnicę między testami POST i PUT:

Podstawowa różnica między żądaniami POST i PUT znajduje odzwierciedlenie w innym znaczeniu URI żądania. Identyfikator URI w żądaniu POST identyfikuje zasób, który będzie obsługiwał zamknięty obiekt. Ten zasób może być procesem akceptującym dane, bramą do innego protokołu lub osobnym podmiotem, który przyjmuje adnotacje. W przeciwieństwie do tego, URI w żądaniu PUT identyfikuje encję dołączoną do żądania - agent użytkownika wie, jaki jest URI, a serwer NIE MOŻE próbować zastosować żądania do jakiegoś innego zasobu.

Nie wspomina nic 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.

Więc proszę, powstrzymaj rozprzestrzenianie się tego popularnego nieporozumienia. Przeczytaj swoje RFC.

Test POST jest uważany za metodę typu fabrycznego. Dołączasz do niego dane, aby tworzyć to, czego chcesz, a wszystko, co jest po drugiej stronie, wie, co z tym zrobić. PUT służy do aktualizowania istniejących danych pod danym adresem URL lub do tworzenia czegoś nowego, gdy wiesz, jaki będzie URI i jeszcze go nie ma (w przeciwieństwie do POST, który coś utworzy i zwróci adres URL do jeśli to konieczne).

REST prosi programistów o jawne stosowanie metod HTTP w sposób zgodny z definicją protokołu. Ta podstawowa zasada projektowania REST ustanawia mapowanie jeden na jeden między operacjami tworzenia, odczytu, aktualizacji i usuwania (CRUD) a metodami HTTP. Zgodnie z tym mapowaniem:

• Aby utworzyć zasób na serwerze, użyj POST.

• Aby pobrać zasób, użyj GET.

• Aby zmienić stan zasobu lub zaktualizować go, użyj PUT.

• Aby usunąć lub usunąć zasób, użyj DELETE.

Więcej informacji: RESTful Web Services: podstawy od IBM

Zastosowanie jednego lub drugiego powinno być dość proste, ale złożone sformułowania są dla wielu z nas źródłem zamieszania.

Kiedy ich używać:

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

  Sidenote: Użyj, PATCHjeśli chcesz zaktualizować część zasobu.

• Użyj, POSTgdy chcesz dodać zasób podrzędny do zbioru zasobów.
  Przykład:POST => /resources

Ogólnie:

• Zasadniczo w praktyce zawsze używaj PUTdo operacji UPDATE .
• Zawsze używaj POSTdo operacji UTWÓRZ .

Przykład:

GET / firma / raporty => Pobierz wszystkie raporty
GET / firma / raporty / {id} => Uzyskaj informacje o raporcie identyfikowane przez „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 o raporcie zidentyfikowanym przez „id”
DELETE / firma / raporty / {id} => Usuń raport za pomocą „id”

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

GET : Żądania za pomocą GET pobierają tylko dane, to znaczy żąda 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 ładunkiem żądania

PATCH : Służy do stosowania częściowych modyfikacji zasobu

DELETE : Usuwa określony zasób

TRACE : Wykonuje test pętli zwrotnej wiadomości wzdłuż ścieżki do zasobu docelowego, zapewniając użyteczny mechanizm debugowania

OPTIONS : Służy do opisywania opcji komunikacji dla zasobu docelowego, klient może określić adres URL dla metody OPTIONS lub gwiazdkę (*), aby odnosić się do całego serwera.

HEAD : Pyta o odpowiedź identyczną z odpowiedzią na żądanie GET, ale bez treści odpowiedzi

CONNECT : Ustanawia tunel do serwera zidentyfikowanego przez zasób docelowy, może być używany do uzyskiwania dostępu do stron internetowych korzystających z SSL (HTTPS)

Wykorzystanie REST

POST służy do utworzenia nowego zasobu, a następnie zwraca zasób URI

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

To połączenie może utworzyć nową książkę i zwrócić tę książkę URI

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

PUT służy do zastąpienia zasobu, jeśli taki zasób istnieje, po prostu go zaktualizuj, ale jeśli ten zasób nie istnieje, utwórz go,

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

Gdy PUTwiemy, identyfikator zasobu, ale POSTzwróci nowy identyfikator zasobu

Wykorzystanie niezgodne z REST

POST służy do zainicjowania akcji po stronie serwera, ta akcja może, ale nie musi tworzyć zasób, ale ta akcja będzie miała wpływ na stronę, zawsze zmieni coś na serwerze

PUT służy do umieszczania lub zastępowania dosłownych treści pod określonym adresem URL

Kolejna różnica w obu stylach REST-ful i nie REST-ful

POST jest operacją niebędącą idempotentną: spowoduje kilka zmian, jeśli zostanie wykonana wiele razy z tym samym żądaniem.

PUT jest Idempotentna Operacja: Nie wywoła żadnych skutków ubocznych, jeśli zostanie wykonana wielokrotnie z tym samym żądaniem.

Warto wspomnieć, że POSTjest przedmiotem częstych ataków typu Cross-Site Request Forgery (CSRF), podczas gdy PUTtak nie jest.

Poniższe CSRF niePUT są możliwe w przypadku wizyty ofiary attackersite.com.

Skutkiem ataku jest to, że poszkodowany nieumyślnie usunie użytkownika tylko dlatego, że (ofiara) został zalogowany jako adminon target.site.com, zanim wizyty attackersite.com:

Normalne żądanie (pliki cookie są wysyłane): ( PUTnie jest obsługiwaną wartością atrybutu)

Kod na attackersite.com:

<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>

Żądanie XHR (pliki cookie są wysyłane): ( PUTwywołałoby żądanie inspekcji wstępnej, którego odpowiedź uniemożliwiłaby przeglądarce żądanie deleteUserstrony)

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

W prostych słowach możesz powiedzieć:

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

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

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

4.HTTP Patch: Służy do częściowej aktualizacji przedmiotu

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

W rzeczywistości nie ma różnicy poza ich tytułem. W rzeczywistości istnieje podstawowa różnica między GET a innymi. Metodą „GET” -Request wysyłasz dane w wierszu adresu url, które są najpierw oddzielone znakiem zapytania, a następnie znakiem &.

Ale przy użyciu metody żądania „POST” nie można przekazywać danych przez adres URL, ale należy przekazać dane jako obiekt w tak zwanym „ciele” żądania. Po stronie serwera musisz następnie odczytać treść otrzymanej treści, aby otrzymać przesłane dane. Ale z drugiej strony nie ma możliwości wysyłania treści w treści, gdy wysyłasz żądanie „GET”.

Twierdzenie, że „GET” służy wyłącznie do uzyskiwania danych, a „POST” służy do publikowania danych, jest całkowicie błędne. Nikt nie może zabronić Ci tworzenia nowych treści, usuwania istniejących treści, edytowania istniejących treści lub robienia czegokolwiek w backendie, na podstawie danych wysyłanych przez żądanie „GET” lub żądanie „POST”. I nikt nie może zapobiec kodowaniu backendu w taki sposób, że przy żądaniu „POST” klient prosi o pewne dane.

Z żądaniem, bez względu na to, z której metody korzystasz, wywołujesz adres URL i wysyłasz lub nie wysyłasz niektórych danych w celu określenia, które informacje chcesz przekazać do serwera w celu obsługi Twojego żądania, a następnie klient otrzymuje odpowiedź od serwer. Dane mogą zawierać wszystko, co chcesz wysłać, backend może robić z danymi wszystko, co chcesz, a odpowiedź może zawierać dowolne informacje, które chcesz tam umieścić.

Istnieją tylko te dwie PODSTAWOWE METODY. POBIERZ i POST. Ale to ich struktura sprawia, że ​​są różne, a nie to, co kodujesz w backendie. W backendie możesz kodować, co chcesz, z otrzymanymi danymi. Ale w przypadku żądania „POST” musisz wysłać / pobrać dane w ciele, a nie w linii adresu URL, a w przypadku żądania „GET” musisz wysłać / pobrać dane w linii adresu URL, a nie w Ciało. To wszystko.

Wszystkie pozostałe metody, takie jak „PUT”, „DELETE” i tak dalej, mają taką samą strukturę jak „POST”.

Metoda POST jest używana głównie, jeśli chcesz nieco ukryć treść, ponieważ wszystko, co napiszesz w linii adresu URL, zostanie zapisane w pamięci podręcznej, a metoda GET jest taka sama, jak zapisanie linii adresu URL z danymi. Więc jeśli chcesz wysyłać poufne dane, które nie zawsze są koniecznie nazwą użytkownika i hasłem, ale na przykład niektórymi identyfikatorami lub skrótami, których nie chcesz wyświetlać w wierszu adresu URL, powinieneś użyć metody POST .

Również długość adresu 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ć ich z żądaniem GET, ale będziesz musiał użyć żądania POST. Jest to więc kolejny plus dla żądania POST.

Ale obsługa żądania GET jest znacznie łatwiejsza, gdy nie masz skomplikowanego tekstu do wysłania. W przeciwnym razie, a jest to kolejny plus dla metody POST, jest to, że w metodzie GET musisz zakodować tekst w url, aby móc wysyłać niektóre symbole w tekście, a nawet spacje. Ale dzięki metodzie POST nie masz żadnych ograniczeń, a twoja treść nie musi być w żaden sposób zmieniana ani manipulowana.

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

PUT - Jeśli dwukrotnie wykonamy to samo żądanie przy użyciu PUT przy użyciu tych samych parametrów za każdym razem, drugie żądanie nie będzie miało żadnego efektu. Właśnie dlatego PUT jest zwykle używany w scenariuszu aktualizacji, wywoływanie aktualizacji więcej niż raz z tymi samymi parametrami nie robi nic więcej niż połączenie początkowe, dlatego PUT jest idempotentny.

POST nie jest idempotentny, na przykład Create utworzy dwa osobne wpisy w celu, dlatego nie jest idempotentny, więc CREATE jest szeroko stosowany w POST.

Wykonanie tego samego wywołania za pomocą POST z tymi samymi parametrami za każdym razem spowoduje dwie różne rzeczy, dlatego też POST jest powszechnie używany w scenariuszu Utwórz