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?

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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 .

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.

POST może przenosić duże dane, podczas gdy GET nie.

Ale ogólnie rzecz biorąc, nie chodzi o niedociągnięcie GET, a raczej o konwencję, jeśli chcesz, aby twoja strona internetowa / aplikacja działała ładnie.

Zajrzyj na http://www.w3.org/2001/tag/doc/whenToUseGet.html

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.

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

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.

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.

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.

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:

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

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.

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.

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.

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

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.