Kiedy używasz POST, a kiedy GET?


343

Z tego, co mogę zebrać, są trzy kategorie:

  1. Nigdy nie używaj GETi nie używajPOST
  2. Nigdy nie używaj POSTi nie używajGET
  3. Nie ma znaczenia, którego używasz.

Czy mam rację zakładając te trzy przypadki? Jeśli tak, jakie są przykłady z każdego przypadku?


1
To w rzeczywistości absolutnie nieprawda. Zarówno GET, jak i POST są widoczne w tym samym stopniu, jeśli sprawdzisz nagłówki wysłane przez przeglądarkę, zobaczysz listę par klucz-wartość, które publikujesz
Velimir Tchatchevsky,


1
Nie ma standardowego sposobu kodowania więcej niż nazwa -> pary wartości w ciągach zapytań, więc jeśli twoje żądania nie są bardzo proste (tj. Brak tablic lub zagnieżdżonych struktur danych), powinieneś rozważyć tylko POST, który zapewnia pole treści, które można użyć z formatami kodowania (JSON, XML itp.).
themihai

Odpowiedzi:


376

Używaj POSTdo destrukcyjnych działań, takich jak tworzenie (zdaję sobie sprawę z ironii), edytowanie i usuwanie, ponieważ nie możesz trafić POSTakcji w pasek adresu przeglądarki. Użyj, GETgdy jest to bezpieczne, aby umożliwić osobie wezwanie akcji. A więc taki adres URL:

http://myblog.org/admin/posts/delete/357

Powinieneś przejść do strony z potwierdzeniem, zamiast po prostu usunąć element. W ten sposób znacznie łatwiej uniknąć wypadków.

POSTjest również bezpieczniejszy niż GET, ponieważ nie umieszczasz informacji w adresie URL. Dlatego użycie GETjako methodformularza HTML, który zbiera hasło lub inne poufne informacje, nie jest najlepszym pomysłem.

Ostatnia uwaga: POSTmoże przesyłać większą ilość informacji niż GET. „POST” nie ma ograniczeń wielkości przesyłanych danych, a „GET” jest ograniczony do 2048 znaków.


82
Odpowiedzi na żądania GET mogą zostać zatrzymane. Odpowiedzi na POST nie mogą.
mkoeller,

31
W jaki sposób nie umieszczanie informacji w adresie URL zwiększa bezpieczeństwo? (Przy okazji, jestem jednym z tych, którzy uważają, że fałszywe poczucie bezpieczeństwa jest bardziej niebezpieczne niż brak bezpieczeństwa).
ePharaoh

42
@ePharaoh: Zatrzymuje ludzi czytających hasła, patrząc przez ramię użytkownika na pasek adresu.
Quentin

35
@ePharaoh: „Ujawnienie nieco mniejszej liczby przypadkowym obserwatorom” byłoby prawdopodobnie lepszym sformułowaniem niż „bezpieczniejsze” - adresy URL mogą znajdować się w wielu miejscach, takich jak dzienniki, odsyłacze, pamięci podręczne. Masz oczywiście rację, to nie zwiększa bezpieczeństwa - ale ogranicza najgorsze niepewne praktyki (patrz także: thedailywtf.com/Articles/The_Spider_of_Doom.aspx )
Piskvor opuścił budynek

24
@David Dorward: Lub bardziej popularna nazwa: atak barku
Idan K

206

W skrócie

  • Użyj GETdla safe andidempotentwniosków
  • Użyj POSTdla neither safe nor idempotentwniosków

W szczegółach Dla każdego jest odpowiednie miejsce. Nawet jeśli nie przestrzegasz zasad RESTful , możesz wiele zyskać na wiedzy o REST i sposobie działania podejścia zorientowanego na zasoby.

Aplikacja RESTful będzie use GETs działać dla obu operacji safe and idempotent.

ZA safeOperacja jest operacją, która ma not change the datawymagane.

Na idempotentOperacja jest taka, w której wynik będzie be the samebez znaczenia, ile razy można zażądać go.

Jest oczywiste, że ponieważ GET są używane do bezpiecznych operacji, są one również automatycznie idempotentne . Zazwyczaj GET służy do pobierania zasobu (na przykład pytania i powiązanych odpowiedzi na temat przepełnienia stosu) lub gromadzenia zasobów.

Użyje aplikacji RESTful PUTs do operacji, które są not safe but idempotent.

Wiem, że pytanie dotyczyło GET i POST, ale wrócę do POST za sekundę.

Zazwyczaj PUT jest używany do edycji zasobu (na przykład edycja pytania lub odpowiedzi na temat przepełnienia stosu).

POSTBędą wykorzystywane do każdej operacji, która jestneither safe or idempotent .

Zazwyczaj POST byłby użyty do utworzenia nowego zasobu, na przykład do utworzenia NOWEGO pytania SO (chociaż w niektórych projektach PUT byłby również do tego użyty).

Jeśli uruchomisz POST dwa razy, utworzysz DWIE nowe pytania.

Jest też operacja DELETE, ale zgaduję, że mogę to tam zostawić :)

Dyskusja

W praktyce współczesne przeglądarki internetowe zazwyczaj niezawodnie obsługują tylko metody GET i POST (wszystkie te operacje można wykonywać za pomocą wywołań javascript, ale pod względem wprowadzania danych w formularzach i naciskania przycisku przesłania zazwyczaj dostępne są dwie opcje). W aplikacji RESTful test POST często jest zastępowany w celu zapewnienia wywołań PUT i DELETE.

Ale nawet jeśli nie przestrzegasz zasad RESTful, warto zastanowić się nad użyciem GET do pobierania / przeglądania informacji i POST do tworzenia / edycji informacji.

Nigdy nie powinieneś używać GET do operacji, która zmienia dane. Jeśli wyszukiwarka zaindeksuje link do Twojej zła operacji lub zakładek klienta, może to oznaczać duże problemy.


jeśli utworzysz zasób APIREST do logowania, który wybierzesz, jest to bezpieczne i idempotentne, goszczę.
jhonny lopez

1
Bezpieczne uzyskanie nie jest automatycznie idempotentne. Zestaw wyników może być inny przy tym samym braku zapytania destrukcyjnego.
RichieHH

1
Sposób, w jaki to napisałeś, coś w stylu „GET currenttime” byłoby błędne, ponieważ nie jest idempotentne (w tym sensie, że powtarzające się zapytania mogą dawać różne wyniki); w rzeczywistości wszystko , o co pytano, może z czasem ulec zmianie. Dlatego należy wyrażać idempotencję raczej w kategoriach skutków ubocznych samego zapytania . Ponieważ samo pytanie o aktualny czas nie ma skutków ubocznych , jest to - jak można się spodziewać - idealny kandydat do GET, a nie POST.
Hagen von Eitzen

79

Użyj GET, jeśli nie przeszkadza ci powtarzanie żądania (to znaczy, że nie zmienia stanu).

Użyj POST, jeśli operacja zmienia stan systemu.


1
Skoro formularz zmienia stan systemu, dlaczego domyślną metodą znacznika formularza HTML jest GET?
ziiweb

3
@ user248959 Czy pole wyszukiwania zmienia stan widoczny? Domyślne ustawienie zostało ustawione dawno temu, prawdopodobnie prawie przez przypadek. Nie zagłębiałem się w historię, aby nawet wiedzieć, czy POST jest opcją w tym momencie, że formularze były opcją.
Douglas Leeder,

@ziiweb Nawet jeśli większość przypadków użycia <form> to POST, lepiej zdefiniować dafault jako „nieszkodliwy” GET. Z punktu widzenia bezpieczeństwa może się to wydawać absurdalne, gdy prowadzi do danych ujawnionych w plikach dziennika itp., Ale jest odporne na awarie w odniesieniu do danych po stronie serwera (serwer nie powinien modyfikować danych po GET). Podejrzewam, że dzisiaj można by inaczej ustawić fokus (najlepiej, porzucając wszelkie domyślne i wprowadzając methodobowiązkowe)
Hagen von Eitzen,

Załóżmy, że mam punkt końcowy, który akceptuje plik jako dane wejściowe, wykonuje pewne przetwarzanie pliku (przykład - wyodrębnianie danych na podstawie wyrażenia regularnego) i zwraca dane JSON, a następnie mogę użyć żądania GET, aby przesłać plik na serwer. Czy powinienem użyć żądania POST?
zmienna

67

Krótka wersja

POBIERZ: Zwykle używany do przesłanych żądań wyszukiwania lub każdego żądania, w którym użytkownik ma mieć możliwość ponownego wyświetlenia dokładnej strony.

Zalety GET:

  • Adresy URL można bezpiecznie dodawać do zakładek.
  • Strony można bezpiecznie ponownie załadować.

Wady GET:

  • Zmienne są przekazywane przez adres URL jako pary nazwa-wartość. (Zagrożenie dla bezpieczeństwa)
  • Ograniczona liczba zmiennych, które można przekazać. (Na podstawie przeglądarki. Na przykład Internet Explorer jest ograniczony do 2048 znaków ).

POST: Używany do żądań o wyższym poziomie bezpieczeństwa, w których dane mogą być użyte do zmiany bazy danych lub strony, której nie chcesz, aby ktoś dodawał do zakładek.

Zalety POST:

  • Pary nazwa-wartość nie są wyświetlane w adresie URL. (Bezpieczeństwo + = 1)
  • Nieograniczoną liczbę par nazwa-wartość można przekazać za pomocą POST. Odniesienie.

Wady POST:

  • Strona wykorzystująca dane POST nie może być zakładką. (Jeśli chcesz.)

Dłuższa wersja

Bezpośrednio z protokołu przesyłania hipertekstu - HTTP / 1.1 :

9.3 GET

Metoda GET oznacza pobieranie wszelkich informacji (w formie encji) zidentyfikowanych przez URI żądania. Jeśli identyfikator URI żądania odnosi się do procesu generowania danych, to dane wytworzone zostaną zwrócone jako byt w odpowiedzi, a nie tekst źródłowy procesu, chyba że tekst ten jest wynikiem procesu.

Semantyka metody GET zmienia się na „warunkowy GET”, jeśli komunikat żądania zawiera pole nagłówka If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match lub If-Range. Warunkowa metoda GET wymaga, aby jednostka została przesłana tylko w okolicznościach opisanych w polach warunkowego nagłówka. Warunkowa metoda GET ma na celu zmniejszenie niepotrzebnego użycia sieci, umożliwiając odświeżanie buforowanych jednostek bez konieczności wielokrotnego żądania lub przesyłania danych przechowywanych już przez klienta.

Semantyka metody GET zmienia się na „częściowy GET”, jeśli komunikat żądania zawiera pole nagłówka Range. Częściowe żądanie GET wymaga przeniesienia tylko części jednostki, jak opisano w sekcji 14.35. Metoda częściowego GET ma na celu zmniejszenie niepotrzebnego użycia sieci, umożliwiając ukończenie częściowo odzyskanych jednostek bez przesyłania danych przechowywanych już przez klienta.

Odpowiedź na żądanie GET jest buforowalna, tylko wtedy, gdy spełnia wymagania dotyczące buforowania HTTP opisane w sekcji 13.

Uwagi dotyczące bezpieczeństwa w przypadku formularzy znajdują się w sekcji 15.1.3.

9.5 POST

Metoda POST służy do żądania, aby serwer źródłowy zaakceptował jednostkę zawartą w żądaniu jako nowego podwładnego zasobu określonego przez identyfikator URI żądania w wierszu żądania. POST został zaprojektowany, aby umożliwić jednolitą metodę obejmującą następujące funkcje:

  • Adnotacja istniejących zasobów;

  • Publikowanie wiadomości na tablicy ogłoszeń, w grupie dyskusyjnej, na liście mailingowej lub w 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.

Rzeczywista funkcja wykonywana metodą POST jest określana przez serwer i zwykle zależy od URI żądania. Wysłana jednostka jest podporządkowana temu identyfikatorowi URI w taki sam sposób, w jaki plik jest podporządkowany katalogowi zawierającemu go, artykuł z wiadomościami jest podporządkowany grupie dyskusyjnej, do której jest wysyłany, lub rekord jest podporządkowany bazie danych.

Czynność wykonana metodą POST może nie skutkować zasobem, który można zidentyfikować za pomocą identyfikatora URI. W takim przypadku albo 200 (OK), albo 204 (Brak treści) jest odpowiednim statusem odpowiedzi, w zależności od tego, czy odpowiedź zawiera encję, która opisuje wynik.


2
„Strony, w której wykorzystano dane postu, nie można dodać do zakładek”: cóż, to zaleta, nie? Prawdopodobnie nie chcesz, aby twoje zapytanie zmieniające dane było dodane do zakładek.
Piskvor opuścił budynek

Podejrzewam, że jeśli za każdym razem używałeś postu, używałeś go do celów bezpieczeństwa, to byłaby to zaleta. Zwykle tak jest, ale istnieje limit długości w GET. Może ktoś po prostu przekazuje mnóstwo danych niezwiązanych z bezpieczeństwem i chciałby dodać stronę do zakładek? Kto wie ...
Cimplicity

Jeśli chodzi o wadę GET, a mianowicie to, że „Zmienne są przekazywane przez URL jako pary nazwa-wartość”, czy MVC wyeliminowałoby ten problem z powodu routingu i wynikowych przyjaznych adresów URL?
MrBoJangles,

@MrBoJangles: Używanie ładnych adresów URL nie zapobiega wspomnianemu ryzyku „osoby spoglądającej przez ramię”. Uwaga dodatkowa: MVC nie wymaga routingu z ładnymi adresami URL, a routing z ładnymi adresami URL nie wymaga MVC; czasami są używane razem, ale mogą być również używane osobno.
icktoofay

W świecie .NET, dla wszystkich praktycznych celów, ładne możliwości url = MVC. Przypuszczam, że możesz zrobić kilka przeróbek IIS lub niektóre dziwne oparte na kodzie, ale są jeszcze mniej przyjemne. MVC, oczywiście, o zwycięstwo.
MrBoJangles

28

Pierwszą ważną rzeczą jest znaczenie GET kontra POST:

  • Użyj GET, aby ... uzyskać ... trochę informacji z serwera,
  • podczas gdy POST powinien być używany do wysyłania niektórych informacji do serwera.


Następnie kilka rzeczy, które można zauważyć:

  • Korzystając z GET, użytkownicy mogą używać przycisku „Wstecz” w przeglądarce i mogą dodawać zakładki do stron
  • Istnieje limit wielkości parametrów, które można przekazać jako GET (2 KB dla niektórych wersji Internet Explorera, jeśli się nie mylę) ; limit jest znacznie większy dla testu POST i ogólnie zależy od konfiguracji serwera.


W każdym razie nie sądzę, że moglibyśmy „żyć” bez GET: pomyśl, ile adresów URL używasz z parametrami w ciągu zapytania, każdego dnia - bez GET wszystkie one nie działałyby ;-)


Cóż, gdyby wszyscy używali ładnych adresów URL w stylu GET: http://example.com/var1/value1/var2/value2/var3/value3moglibyśmy „technicznie” już nie mieć GET…
Tyler Carter

5
@ Chacha102 Tyle, że nadal musisz zdobyć ten zasób. Prawie wszystkie strony, obrazy, skrypty itp. Są ładowane do przeglądarek internetowych za pomocą GET.
Ryan

3
@ Chacha102 - Nawet www.mypage.com/contact/zastosowania GET wewnętrznie do czegoś takiegoindex.php?url=/contact/
Thiago Belem

1
Nacisk na limit rozmiaru GET! Ponadto parametry GET są zawarte w zakładkach, a POST nie. I użytkownik może odświeżyć stronę żądaną przez GET, ale nie stronę żądaną POST (bez ostrzeżenia o ponownym wysłaniu informacji).
Ricket

12

Oprócz różnicy ograniczeń długości w wielu przeglądarkach internetowych istnieje również różnica semantyczna. GET-y powinny być „bezpieczne”, ponieważ są operacjami tylko do odczytu, które nie zmieniają stanu serwera. Testy POST zazwyczaj zmieniają stan i ostrzegają przy ponownym przesyłaniu. Przeszukiwacze sieci wyszukiwarek mogą uzyskiwać GET, ale nigdy nie powinni wykonywać POST.

Użyj GET, jeśli chcesz odczytać dane bez zmiany stanu, i użyj POST, jeśli chcesz zaktualizować stan na serwerze.


+1. Jest to kluczowa różnica koncepcyjna w stosunku do RFC, z której wynika wszystko inne. w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3
Frank Farmer

8

Moją ogólną zasadą jest używanie Get, gdy wysyłasz żądania do serwera, które nie zamierzają zmieniać stanu. Posty są zarezerwowane dla żądań do serwera, które zmieniają stan.


8

Jedną praktyczną różnicą jest to, że przeglądarki i serwery WWW mają ograniczenie liczby znaków, które mogą istnieć w adresie URL. Różni się od aplikacji do aplikacji, ale z pewnością można ją trafić, jeśli masz textareaw swoich formularzach.

Kolejna gotcha z GET-ami są one indeksowane przez wyszukiwarki i inne systemy automatyczne. Google miał kiedyś produkt, który wstępnie pobierałby linki na oglądanej stronie, więc ładowanie ich byłoby szybsze, gdybyś kliknął te linki. Spowodowało to poważne spustoszenie w witrynach, które miały takie linki delete.php?id=1- ludzie stracili całe swoje witryny.


1
Twój serwer prawdopodobnie ma również na to ograniczenia.
Billy ONeal,

Istnieje również limit POST.
chelmertz

1
Świetna uwaga, @BillyONeal, dodałem to. @Chelmertz Tak, ale mogę to zmienić, jeśli chcę, i to znacznie wyżej. Na przykład wysłałem 1 gigabajt plików do instancji Apache.
ceejayoz

Rozumiem, że adresy URL są indeksowane przez wyszukiwarki. Nie rozumiem, co to ma wspólnego z GET. Mam na myśli, że adres URL nie jest tylko adresem URL?
Honey

1
Wyszukiwarki @Honey podążają za linkami. Linki tworzą żądania GET. Wyszukiwarki nie przesyłają formularzy (gdyby to zrobiły, Google rejestrowałoby konto w Twojej witrynie co kilka dni), a tym samym nie składały żadnych żądań POST.
ceejayoz

7

Użyj GET, jeśli chcesz, aby adres URL odzwierciedlał stan strony. Jest to przydatne do przeglądania dynamicznie generowanych stron, takich jak te widoczne tutaj. POST powinien być używany w formularzu do przesyłania danych, na przykład po kliknięciu przycisku „Opublikuj swoją odpowiedź”. Tworzy również czystszy adres URL, ponieważ nie generuje ciągu parametrów po ścieżce.


6

Ponieważ GET są wyłącznie adresami URL, mogą być buforowane przez przeglądarkę internetową i mogą być lepiej wykorzystywane do rzeczy takich jak stale generowane obrazy. (Ustaw czas wygaśnięcia)

Jeden przykład ze strony gravatar: http://www.gravatar.com/avatar/4c3be63a4c2f539b013787725dfce802?d=monsterid

GET może nieznacznie poprawić wydajność, niektóre serwery WWW zapisują zawartość POST do pliku tymczasowego przed wywołaniem programu obsługi.

Inną rzeczą do rozważenia jest ograniczenie rozmiaru. Pliki GET są ograniczone przez rozmiar adresu URL, 1024 bajty według standardu, chociaż przeglądarki mogą obsługiwać więcej.

Przesyłanie większej ilości danych niż ta powinna wymagać testu POST, aby uzyskać lepszą kompatybilność przeglądarki.

Nawet mniej niż ten limit stanowi problem, jak napisał inny plakat, wszystko w adresie URL może skończyć się w innych częściach interfejsu użytkownika przeglądarki, takich jak historia.


4

Nic nie możesz zrobić per se. Chodzi o to, że nie jesteś powinien zmodyfikować stan serwera przez HTTP GET. Serwery proxy HTTP zakładają, że skoro HTTP GET nie modyfikuje stanu, to czy użytkownik wywołuje HTTP GET raz czy 1000 razy, nie ma znaczenia. Korzystając z tych informacji, zakładają, że bezpieczne jest zwrócenie buforowanej wersji pierwszego HTTP GET. Jeśli złamiesz specyfikację HTTP, ryzykujesz zerwanie klienta HTTP i serwerów proxy na wolności. Nie rób tego :)


Nie tylko przeglądarki liczą na to, że GET jest bezpieczny i idempotentny: pająki wyszukiwarek i przeglądarki pobierające z wyprzedzeniem (jak szybszy Fox) również na tym polegają.
Frank Farmer,

@ gili, w końcu ktoś z prawidłową odpowiedzią. Naprawdę jestem zaskoczony, jak wiele osób pomyliło się. kciuki w górę!
lubos hasko

4

Przechodzi to do koncepcji REST i tego, w jaki sposób Internet był przeznaczony do użycia. Jest doskonały podcast radiu Software Engineering który szczegółowo omawia korzystanie z Get i Post.

Get służy do pobierania danych z serwera, na którym działanie aktualizacji nie powinno być potrzebne. Chodzi o to, że powinieneś mieć możliwość korzystania z tego samego żądania GET w kółko i zwracania tych samych informacji. Adres URL zawiera informację „get” w ciągu zapytania, ponieważ miał być łatwy do wysłania do innych systemów i osób takich jak adres, pod którym można coś znaleźć.

Post ma być wykorzystywany (przynajmniej przez architekturę REST, na której opiera się sieć) do przesyłania informacji do serwera / nakazania serwerowi wykonania akcji. Przykłady takie jak: Zaktualizuj te dane, Utwórz ten rekord.


„W radiu inżynierii oprogramowania znajduje się doskonały podcast, który szczegółowo omawia korzystanie z Get i Post”. Gdzie to jest?
yeeen

Dodałem do niego link.
kemiller2002

Oto ten link: se-radio.net/2008/05/episode-98-stefan-tilkov-on-rest Ja również edytowałem powyższy link, chociaż nie mam uprawnień do edycji i musi być recenzowany itp.
MrBoJangles

Załóżmy, że mam punkt końcowy, który akceptuje plik jako dane wejściowe, wykonuje pewne przetwarzanie pliku (przykład - wyodrębnianie danych na podstawie wyrażenia regularnego) i zwraca dane JSON, a następnie mogę użyć żądania GET, aby przesłać plik na serwer. Czy powinienem użyć żądania POST?
zmienna

4

1.3 Szybka lista kontrolna do wyboru HTTP GET lubPOST

Użyj GET, jeśli:

    The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).

Użyj POST, jeśli:

    The interaction is more like an order, or
    The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or
    The user be held accountable for the results of the interaction.

Źródło .


3

Nie widzę problemu z użyciem get, używam go do prostych rzeczy, w których sensowne jest trzymanie rzeczy w ciągu zapytania.

Używanie go do aktualizacji stanu - podobnie jak GET lub delete.php?id=5usuwanie strony - jest bardzo ryzykowne. Ludzie dowiedzieli się, że gdy akcelerator internetowy Google zaczął pobierać adresy URL na stronach - trafił we wszystkie linki „usuń” i wymazał dane ludzi. To samo może się stać z pająkami wyszukiwarek.



3

Z RFC 2616 :

9.3 GET
Metoda GET oznacza pobieranie wszelkich informacji (w formie encji) zidentyfikowanych przez URI żądania. Jeśli identyfikator URI żądania odnosi się do procesu generowania danych, to dane wytworzone zostaną zwrócone jako byt w odpowiedzi, a nie tekst źródłowy procesu, chyba że tekst ten jest wynikiem procesu.


9.5 POST
Metoda POST służy do żądania od serwera źródłowego przyjęcia jednostki zawartej w żądaniu jako nowego podwładnego zasobu określonego przez identyfikator URI żądania w wierszu żądania. POST został zaprojektowany, aby umożliwić jednolitą metodę obejmującą następujące funkcje:

  • Adnotacja istniejących zasobów;
  • Publikowanie wiadomości na tablicy ogłoszeń, w grupie dyskusyjnej, na liście mailingowej lub w 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.

Rzeczywista funkcja wykonywana metodą POST jest określana przez serwer i zwykle zależy od URI żądania. Wysłana jednostka jest podporządkowana temu identyfikatorowi URI w taki sam sposób, w jaki plik jest podporządkowany katalogowi zawierającemu go, artykuł z wiadomościami jest podporządkowany grupie dyskusyjnej, do której jest wysyłany, lub rekord jest podporządkowany bazie danych.

Czynność wykonana metodą POST może nie skutkować zasobem, który można zidentyfikować za pomocą identyfikatora URI. W takim przypadku albo 200 (OK), albo 204 (Brak treści) jest odpowiednim statusem odpowiedzi, w zależności od tego, czy odpowiedź zawiera encję, która opisuje wynik.


2

Używam POST, gdy nie chcę, aby ludzie widzieli QueryString lub gdy QueryString robi się duży. POST jest również potrzebny do przesyłania plików.

Jednak nie widzę problemu z korzystaniem z GET, używam go do prostych rzeczy, w których sensowne jest utrzymywanie rzeczy w QueryString.

Użycie GET pozwoli na linkowanie do konkretnej strony, gdzie POST nie będzie działać.


Dlaczego nie możemy używać GET do przesyłania plików?
zmienna

1

Pierwotnym zamiarem było użycie GET do odzyskania danych i POST miał być czymkolwiek. Zasadą, której używam jest to, że jeśli wysyłam coś z powrotem na serwer, używam POST. Jeśli dzwonię pod adres URL, aby odzyskać dane, używam GET.


1

Przeczytaj artykuł o HTTP w Wikipedii . Wyjaśni, czym jest protokół i co robi:

DOSTAĆ

Żąda reprezentacji określonego zasobu. Należy pamiętać, że GET nie powinien być używany do operacji powodujących skutki uboczne, takich jak używanie go do wykonywania działań w aplikacjach internetowych. Jednym z powodów tego jest to, że GET może być stosowany arbitralnie przez roboty lub roboty, co nie powinno wymagać uwzględnienia skutków ubocznych, które powinno wywołać żądanie.

i

POST Przekazuje dane do przetworzenia (np. Z formularza HTML) do zidentyfikowanego zasobu. Dane są zawarte w treści żądania. Może to spowodować utworzenie nowego zasobu lub aktualizację istniejących zasobów lub obu tych elementów.

W3C ma dokument o nazwie URI, Adresowalność oraz użycie HTTP GET i POST, który wyjaśnia, kiedy z czego korzystać. Cytowanie

1.3 Szybka lista kontrolna do wyboru HTTP GET lub POST

  • Użyj GET, jeśli:
    • Interakcja bardziej przypomina pytanie (tzn. Jest bezpieczną operacją, taką jak zapytanie, operacja odczytu lub wyszukiwanie).

i

  • Użyj POST, jeśli:
    • Interakcja jest bardziej jak zamówienie lub
    • Interakcja zmienia stan zasobu w sposób, który użytkownik postrzega (np. Subskrypcja usługi) lub o Użytkownik ponosi odpowiedzialność za wyniki interakcji.

Jednak przed ostateczną decyzją o użyciu protokołu HTTP GET lub POST należy również wziąć pod uwagę względy wrażliwych danych i względy praktyczne.

Praktycznym przykładem może być przesłanie formularza HTML. Możesz podać post lub get dla akcji formularza. PHP odpowiednio zapełni $ _GET i $ _POST.


1

W PHP POSTlimit danych jest zwykle ustawiany przez użytkownika php.ini. GETUważam, że jest ograniczony ustawieniami serwera / przeglądarki - zwykle około 255bajtów.


1

Od w3schools.com :

Co to jest HTTP?

Protokół HTTP (Hypertext Transfer Protocol) został zaprojektowany w celu umożliwienia komunikacji między klientami a serwerami.

HTTP działa jako protokół żądanie-odpowiedź między klientem a serwerem.

Klientem może być przeglądarka internetowa, a serwerem na komputerze obsługującym witrynę internetową może być serwer.

Przykład: klient (przeglądarka) przesyła żądanie HTTP do serwera; następnie serwer zwraca odpowiedź do klienta. Odpowiedź zawiera informacje o stanie dotyczące żądania i może również zawierać żądaną treść.

Dwie metody żądania HTTP: GET i POST

Dwie najczęściej stosowane metody odpowiedzi na żądanie między klientem a serwerem to: GET i POST.

GET - Żąda danych z określonego zasobu POST - Przekazuje dane do przetworzenia do określonego zasobu

Tutaj wyróżniamy główne różnice:

wprowadź opis zdjęcia tutaj


1
Byłoby znacznie lepiej dla wyszukiwarek i czytelników, aby wprowadzić treść obrazu do odpowiedzi. Również pierwsza część odpowiedzi tak naprawdę nie pomaga w udzieleniu odpowiedzi na pytanie.
Dave Schweisguth,

Skopiuj wklej tutaj - musisz poprawnie zacytować swoje źródło, a licencja źródła musi pozwalać na ponowne użycie, czego nie sądzę, że w3schools robi. Poza tym, czy naprawdę uważasz, że to dodaje coś, czego nie ujęto w pozostałych 25 odpowiedziach?
Benjamin W.

1

Prosta wersja POST GET PUT DELETE

  • użyj GET - gdy chcesz uzyskać dowolny zasób, taki jak Lista danych na podstawie dowolnego identyfikatora lub nazwy
  • użyj POST - gdy chcesz wysłać dowolne dane na serwer. pamiętaj, że POST jest operacją o dużej wadze, ponieważ do aktualizacji powinniśmy użyć PUT zamiast POST wewnętrznie POST utworzy nowy zasób
  • użyj PUT - kiedy Ty

4
„użyj PUT - kiedy ty” Gdzie jest reszta zdania?
Pang

To wspaniale, że komuś podobały się pierwsze dwa pociski tej odpowiedzi tak bardzo, że najwyraźniej poparły go bez ostatniego pocisku haha: '-)
pooley1994

0

Cóż, jedną ważną rzeczą jest to, że wszystko, co przesyłasz, GETzostanie ujawnione za pośrednictwem adresu URL. Po drugie, jak mówi Ceejayoz, istnieje limit znaków w adresie URL.


0

Inna różnica polega na tym, że POST zazwyczaj wymaga dwóch operacji HTTP, podczas gdy GET wymaga tylko jednej.

Edycja: powinienem wyjaśnić - dla typowych wzorców programowania. Generalnie odpowiadanie na POST prostą stroną HTML jest wątpliwym projektem z różnych powodów, z których jednym jest denerwujące „musisz ponownie przesłać ten formularz, czy chcesz to zrobić?” po naciśnięciu przycisku Wstecz.


2
POST nie wymaga 2 operacji HTTP.
Billy ONeal,

3
post-redirect-get wymaga 2 operacji: en.wikipedia.org/wiki/Post/Redirect/Get
cherouvim

1
POST może wymagać 2 podróży w obie strony do serwera - częstym wzorcem jest POST z expect: 100-continuenagłówkiem, a następnie wysyłanie danych tylko wtedy, gdy serwer odpowiada za pomocą 100 CONTINUE.
Frank Farmer,

Niezły artykuł cherouvim, nigdy nie wiedziałem, że wzór ma nazwę.
Plynx

@cherouvim: Post przekierowuje get robi, ale zwykły post nie. Równie dobrze możesz uzyskać przekierowanie z tymi samymi wynikami. Nie ma to nic wspólnego z protokołem używanym przez formularz do przesłania.
Billy ONeal,

0

Zgodnie z odpowiedzią innych, w przypadku get istnieje ograniczenie rozmiaru adresu URL, a pliki można przesyłać tylko pocztą.

Chciałbym dodać, że można dodawać rzeczy do bazy danych za pomocą polecenia get i perform z postem. Kiedy skrypt otrzymuje post lub get, może zrobić wszystko, co chce autor. Uważam, że brak zrozumienia wynika z sformułowania, które wybrała książka lub z tego, jak ją czytasz.

Autor skryptu powinien używać postów do zmiany bazy danych i używać get tylko do pobierania informacji.

Języki skryptowe zapewniały wiele środków dostępu do żądania. Na przykład PHP pozwala na użycie $_REQUESTdo pobrania posta lub get. Należy tego unikać na rzecz bardziej szczegółowych $_GETlub $_POST.

W programowaniu internetowym jest znacznie więcej miejsca na interpretację. Jest to, co należy i co można zrobić, ale to, co jest lepsze, często jest przedmiotem dyskusji. Na szczęście w tym przypadku nie ma dwuznaczności. Państwo powinno używać posty zmianę danych, a powinno używać się do pobierania informacji.


0

Gorgapor, mod_rewritewciąż często wykorzystuje GET. Pozwala jedynie przetłumaczyć bardziej przyjazny adres URL na adres URL z GETciągiem zapytania.


-1

Dane HTTP Post nie mają określonego limitu ilości danych, ponieważ różne przeglądarki mają różne limity GET. RFC 2068 stanowi:

Serwery powinny zachować ostrożność w zależności od długości identyfikatora URI powyżej 255 bajtów, ponieważ niektóre starsze implementacje klienta lub proxy mogą nie obsługiwać tych długości w odpowiedni sposób

W szczególności powinieneś mieć odpowiednie konstrukcje HTTP do tego, do czego są używane. HTTP GET nie powinny mieć skutków ubocznych i mogą być bezpiecznie odświeżane i przechowywane przez proxy HTTP itp.

POST HTTP są używane, gdy chcesz przesłać dane do zasobu URL.

Typowym przykładem użycia HTTP GET jest wyszukiwanie, tzn. Wyszukiwanie? Zapytanie = moje + zapytanie Typowym przykładem użycia HTTP POST jest przesyłanie opinii do formularza online.

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.