Czego potrzebują metody takie jak GET i POST w protokole HTTP?

Czy nie możemy zaimplementować protokołu HTTP, używając tylko treści żądania i odpowiedzi?

Na przykład adres URL będzie zawierał żądanie, które zostanie zamapowane na funkcję w zależności od języka programowania po stronie serwera, powiedzmy serwlet, aw odpowiedzi zostanie wysłana odpowiedź HTML i JavaScript.

Dlaczego protokół HTTP ma pojęcie metod?

Na podstawie odpowiedzi rozumiem, dlaczego istnieje koncepcja metod. Prowadzi to do kolejnego powiązanego pytania:

Na przykład w łączu do tworzenia Gmaila żądanie PUT / POST i dane zostaną wysłane. Skąd przeglądarka rozpoznaje, której metody użyć? Czy strona Gmaila wysłana przez serwer zawiera nazwę metody używanej podczas wywoływania żądania komponowania Gmaila? kiedy wywołujemy www.gmail.com, musi to być metoda GET, skąd przeglądarka wie, że tej metody należy użyć?

PS : Nie mam wystarczających kredytów, aby komentować odpowiedzi, więc nie jestem w stanie komentować wielu pytań zadawanych przez ludzi związanych z intencją stojącą za tym pytaniem.

Jak pokazują niektóre odpowiedzi, możemy tworzyć nowych użytkowników metodą DELETE, to rodzi pytanie o zamiar pojęcia w protokole http, ponieważ pod koniec dnia całkowicie zależy od serwerów, na jaką funkcję chcą mapować adres URL . Dlaczego klient powinien informować serwery, jakich metod użyć dla adresu URL.

Uwaga: pytanie zmieniło się / zostało wyjaśnione od czasu pierwszej odpowiedzi. Kolejną odpowiedzią na ostatnią iterację pytania jest druga reguła horyzontalna

Czego potrzebują metody takie jak GET i POST w protokole HTTP?

Wraz z kilkoma innymi rzeczami, takimi jak formaty nagłówków, reguły rozdzielania nagłówków i treści, stanowią podstawę protokołu HTTP

Czy nie możemy zaimplementować protokołu HTTP, używając tylko treści żądania i odpowiedzi?

Nie, ponieważ to, co stworzyłeś, nie byłoby protokołem HTTP

Na przykład adres URL będzie zawierał żądanie, które zostanie zamapowane na funkcję w zależności od języka programowania po stronie serwera, powiedzmy serwlet, aw odpowiedzi zostanie wysłana odpowiedź HTML i JavaScript.

Gratulacje, właśnie wymyśliłeś nowy protokół! Teraz, jeśli chcesz skonfigurować organ normalizacyjny do prowadzenia i utrzymywania go, rozwijania go itp., Może pewnego dnia wyprzedzić HTTP

Rozumiem, że to trochę język w policzek, ale nie ma nic magicznego w Internecie, TCP / IP lub komunikacji między serwerami i klientami. Otwierasz połączenie i wysyłasz kilka słów, tworząc rozmowę. Rozmowa naprawdę musi być zgodna z niektórymi ratyfikowanymi specyfikacjami na obu końcach, jeśli prośby mają zostać zrozumiane i dostarczone rozsądne odpowiedzi. Nie różni się to niczym od dialogu na świecie. Mówisz po angielsku, twój sąsiad mówi po chińsku. Mam nadzieję, że machanie ręką, wskazywanie i drżenie pięścią wystarczą, aby przekazać wiadomość, że nie chcesz, aby parkował samochód przed twoim domem.

Z powrotem w Internecie, jeśli otworzysz gniazdo serwera WWW zgodnego z HTTP i wyślesz:

EHLO
AUTH LOGIN

(Rozpoczęcie transmisji wiadomości e-mail SMTP), a następnie nie uzyskasz sensownej odpowiedzi. Możesz stworzyć najdoskonalszego klienta zgodnego z SMTP, ale twój serwer nie chce z nim rozmawiać, ponieważ w tej rozmowie chodzi o wspólny protokół - brak wspólnego protokołu, brak radości.

Dlatego nie możesz zaimplementować protokołu HTTP bez implementacji protokołu HTTP; jeśli to, co piszesz, nie jest zgodne z protokołem, to po prostu nie jest protokołem - to coś innego i nie będzie działać zgodnie z protokołem

Jeśli bierzemy na chwilę twój przykład; gdzie klient łączy się i po prostu podaje coś, co wygląda jak adres URL. A serwer to rozumie i po prostu wysyła coś, co wygląda jak HTML / JS (strona internetowa), to na pewno może działać. Co jednak zaoszczędziłeś? Kilka bajtów na temat nie mówienia GET? Niewiele więcej o zrzucaniu tych irytujących nagłówków .. Serwer też trochę oszczędził - ale co, jeśli nie możesz zorientować się, co ci wysłał? Co się stanie, jeśli poprosisz o adres URL, który kończy się w JPEG, i przesłał ci kilka bajtów, które tworzą obraz, ale jest w formacie PNG? W tym niekompletny PNG. Jeśli tylko mieliśmy nagłówek, który powiedział, jak wiele bajtów zostało dziejedo wysłania, to wiedzielibyśmy, czy liczba otrzymanych bajtów to tak naprawdę cały plik, czy nie. Co jeśli serwer zgzipuje odpowiedź, aby zaoszczędzić trochę przepustowości, ale ci nie powie? Zamierzasz wydać znaczną moc obliczeniową, próbując dowiedzieć się, co ona wysłała.

Na koniec dnia potrzebujemy metainformacji - informacji o informacjach; potrzebujemy nagłówków; potrzebujemy plików, które mają nazwy, rozszerzenia, utworzone daty. Potrzebujemy ludzi, aby obchodzili urodziny, mówili „dziękuję” i „dziękuję” itd. - świat jest pełen protokołów i informacji o kontekście, więc nie musimy siadać i cały czas pracować od zera. Kosztuje trochę miejsca do przechowywania, ale łatwo jest tego warte

Czy wdrożenie różnych metod HTTP jest naprawdę potrzebne?

Prawdopodobnie nie trzeba implementować całego określonego protokołu, i zwykle dotyczy to wszystkiego. Nie znam każdego słowa w języku angielskim; mój chiński sąsiad jest również programistą, ale w innej branży i nie zna nawet chińskiego w odniesieniu do niektórych terminów używanych w mojej branży, nie mówiąc już o angielskim. Dobrą rzeczą jest to, że oboje możemy odebrać dokument dotyczący implementacji HTTP, on może napisać serwer, a ja mogę napisać klienta, w różnych językach programowania na różnych architekturach, i nadal działają, ponieważ przestrzegają protokołu

Może się zdarzyć, że żaden z twoich użytkowników nigdy nie wyda niczego innego niż żądanie GET, nie użyje trwałych połączeń, nie wyśle ​​niczego innego niż JSON jako treści lub nie będzie musiał zaakceptować niczego innego niż tekst / zwykły, abyś mógł napisz naprawdę sparaliżowany serwer WWW, który spełnia tylko bardzo ograniczone wymagania przeglądarki klienta. Ale nie można po prostu arbitralnie zdecydować o zniesieniu podstawowych zasad, które sprawiają, że „część tekstu przekazywanego przez gniazdo” jest tym, czym jest HTTP; nie można porzucić podstawowego pojęcia, że ​​żądanie będzie ciągiem takim jak:

VERB URL VERSION
header: value

maybe_body

Odpowiedź będzie miała wersję, kod statusu i może nagłówki. Jeśli to zmienisz - to już nie jest HTTP - to coś innego i będzie działać tylko z czymś, co zostało zaprojektowane, aby to zrozumieć. W tych definicjach HTTP jest tym, czym jest, więc jeśli chcesz go wdrożyć, musisz postępować zgodnie z definicjami

Aktualizacja

Twoje pytanie nieco się zmieniło, oto odpowiedź na pytanie:

Dlaczego protokół HTTP ma pojęcie metod?

Historycznie trzeba zdawać sobie sprawę z tego, że ich konstrukcja i implementacja były o wiele bardziej nieelastyczne, nawet do tego stopnia, że ​​skrypty nie istniały, a nawet pogląd, że strony mogą być dynamiczne, generowane w pamięci w locie i przesuwane w dół gniazda zamiast tego bycia statycznym plikiem na dysku, który został zażądany przez klienta i odczytany i wypchnięty z gniazda, nie istniał. W związku z tym, że bardzo wczesna strona internetowa skupiała się na pojęciu stron statycznych, które zawierały linki do innych stron, wszystkie strony istniały na dysku, a nawigacja byłaby prowadzona przez terminal głównie wysyłający żądania GET dla stron pod adresami URL, serwer byłby w stanie zmapować adres URL pliku na dysku i wyślij go. Pojawiło się również przekonanie, że sieć dokumentów, które łączą się ze sobą i gdzie indziej, powinna ewoluować,

Daje to pewien historyczny kontekst dla metod - dawno temu URL był nieelastycznym bitem i w uproszczeniu odnosi się do stron na dysku, więc metoda była przydatna, ponieważ pozwalała klientowi opisać, jaki miał zamiar dla pliku, a serwer przetworzyć metodę w różny sposób. Tak naprawdę nie było pojęcia, że ​​adresy URL są wirtualne lub używane do przełączania lub mapowania w oryginalnej wizji hipertekstu (i tak naprawdę był to tylko tekst)

Nie zamierzam, aby ta odpowiedź była dokumentacją zapisu historycznego z datami i cytowanymi odniesieniami dokładnie wtedy, gdy wszystko zaczęło się zmieniać - do tego prawdopodobnie można przeczytać Wikipedię - ale wystarczy powiedzieć, że z biegiem czasu Internet, aby zyskać większą rozpęd i na każdym końcu połączenia serwer-klient rozszerzamy możliwości tworzenia bogatych wrażeń multimedialnych. Przeglądarki wspierają ogromną liczbę tagów służących do formatowania treści. Każda z nich dąży do wdrożenia niezbędnych funkcji bogactwa multimediów i nowych sposobów sprawiania, że ​​wszystko wygląda niesamowicie.

Po stronie klienta pojawiły się skrypty oraz wtyczki i rozszerzenia przeglądarki, które miały na celu uczynienie przeglądarki niezwykle potężną potęgą wszystkiego. Po stronie serwera aktywne było generowanie treści w oparciu o algorytmy lub dane z bazy danych i nadal się rozwija, do tego stopnia, że ​​prawdopodobnie na dysku jest już niewiele plików - na pewno przechowujemy plik obrazu lub skryptu jako plik na serwer WWW i przeglądarka go POBIERAJ, ale w coraz większym stopniu obrazy wyświetlane przez przeglądarkę i uruchamiane przez nią skrypty nie są plikami, które można otworzyć w eksploratorze plików, lecz generowane treści, które są wynikiem niektórych procesów kompilacji wykonywanych na żądanie , SVG, który opisuje, jak narysować piksele zamiast tablicy bitmapowej pikseli, lub JavaScript, który został wysłany z formy skryptu wyższego poziomu, takiego jak TypeScript

Tworząc współczesne strony o wielkości wielu megabajtów, prawdopodobnie tylko niewielka ich część jest teraz poprawiona na dysku; dane bazy danych są sformatowane i przekształcane w HTML, który przeglądarka zużyje, i jest to wykonywane przez serwer w odpowiedzi na wiele różnych procedur programowania, do których odwołuje się w jakiś sposób adres URL

W komentarzach do pytania wspomniałem, że to trochę jak pełne koło. Kiedy komputery kosztowały setki tysięcy i wypełnione pokoje, powszechnym było pozwalanie wielu użytkownikom na korzystanie z jednego super potężnego centralnego komputera za pomocą setek głupich terminali - klawiatury i myszy, zielonego ekranu, wysyłania tekstu, zdobywania wypisać. Z biegiem czasu, gdy moc obliczeniowa rosła, a ceny spadały, ludzie zaczęli mieć komputery stacjonarne mocniejsze niż wczesne komputery mainframe i możliwość uruchamiania potężnych aplikacji lokalnie, więc model mainframe stał się przestarzały. Nigdy jednak nie minęło, ponieważ wszystko ewoluowało, aby przejść w drugą stronę i nieco przywrócić do centralnego serwera zapewniającego większość użytecznych funkcji aplikacji i setki komputerów klienckich, które robią bardzo niewiele oprócz rysowania na ekranie, oraz przesyłanie i odbieranie danych do / z serwera. Ten okres przejściowy, w którym komputer był wystarczająco inteligentny, aby jednocześnie uruchamiać własną kopię słowa i programu Outlook, ustąpił miejsca biuru online, w którym przeglądarka jest urządzeniem do rysowania zdjęć na ekranie i edytowania dokumentu / wiadomości e-mail ” pisząc jako rzecz, która żyje na serwerze, jest tam zapisywana, wysyłana i udostępniana innym użytkownikom, jako że przeglądarka jest tylko powłoką, która zapewnia częściowy widok w dowolnym momencie tej rzeczy, która żyje gdzie indziej

Na podstawie odpowiedzi rozumiem, dlaczego istnieje koncepcja metod. Prowadzi to do kolejnego powiązanego pytania:

Na przykład w łączu do tworzenia Gmaila żądanie PUT / POST i dane zostaną wysłane. Skąd przeglądarka rozpoznaje, której metody użyć?

Domyślnie używa GET, zgodnie z konwencją / specyfikacją, ponieważ to, co jest zadeklarowane, stanie się, gdy wpiszesz adres URL i naciśniesz return

Czy strona Gmaila wysłana przez serwer zawiera nazwę metody używanej podczas wywoływania żądania komponowania Gmaila?

Jest to jedna z kluczowych rzeczy, do których nawiązuję w powyższych komentarzach. We współczesnej sieci nie chodzi już nawet o strony. Gdy strony były plikami na dysku, przeglądarka je otrzymywała. Następnie stały się stronami, które były generowane głównie dynamicznie przez umieszczenie danych w szablonie. Ale nadal wymagało to procesu „poproś o nową stronę z serwera, pobierz stronę, pokaż stronę”. Wymiana stron stała się naprawdę łatwa; nie widziałeś, jak się ładują, zmieniają rozmiar i szarpią układ, więc wyglądało to płynniej, ale wciąż przeglądarka zastępowała jedną całą stronę lub jej część inną

Współczesny sposób robienia rzeczy polega na aplikacji na jednej stronie; przeglądarka ma zapisany w pamięci dokument, który jest wyświetlany w określony sposób, wywołuje skrypty wywołujące thebservr i odzyskuje jakiś samorodek informacji oraz manipuluje dokumentem, tak aby część strony zmieniała się wizualnie, aby pokazać nową informację - wszystko działa bez przeglądarka kiedykolwiek ładuje inną nową stronę; staje się po prostu interfejsem użytkownika, którego części aktualizują się tak, jak typowa aplikacja kliencka, taka jak słowo lub program Outlook. Nowe elementy pojawiają się na wierzchu innych elementów i można je przeciągać wokół symulujących okien dialogowych itp. Wszystko to Jest to silnik skryptowy przeglądarki wysyłający żądania za pomocą dowolnej metody http, której chce deweloper, odzyskujący dane i szturchający dokument rysowany przez przeglądarkę. Można sobie wyobrazić, że nowoczesna przeglądarka to genialne urządzenie, które przypomina coś w rodzaju całego systemu operacyjnego lub wirtualnego komputera; programowalne urządzenie, które ma dość znormalizowany sposób rysowania rzeczy na ekranie, odtwarzania dźwięku, przechwytywania danych wejściowych użytkownika i wysyłania go do przetworzenia. Wszystko, co musisz zrobić, aby narysować swój interfejs użytkownika, to dostarczyć mu html / css, który tworzy interfejs użytkownika, a następnie stale modyfikować HTML, aby przeglądarka zmieniła to, co rysuje. Heck, ludzie są tak przyzwyczajeni do zmiany paska adresu / używania go jako kierunku intencji, że aplikacja na jednej stronie programowo zmieni adres URL, nawet jeśli nie odbywa się nawigacja (żądanie całych nowych stron) Wszystko, co musisz zrobić, aby narysować swój interfejs użytkownika, to dostarczyć mu html / css, który tworzy interfejs użytkownika, a następnie stale modyfikować HTML, aby przeglądarka zmieniła to, co rysuje. Heck, ludzie są tak przyzwyczajeni do zmiany paska adresu / używania go jako kierunku intencji, że aplikacja na jednej stronie programowo zmieni adres URL, nawet jeśli nie jest wykonywana nawigacja (żądanie całych nowych stron) Wszystko, co musisz zrobić, aby narysować swój interfejs użytkownika, to dostarczyć mu html / css, który tworzy interfejs użytkownika, a następnie stale modyfikować HTML, aby przeglądarka zmieniła to, co rysuje. Heck, ludzie są tak przyzwyczajeni do zmiany paska adresu / używania go jako kierunku intencji, że aplikacja na jednej stronie programowo zmieni adres URL, nawet jeśli nie odbywa się nawigacja (żądanie całych nowych stron)

kiedy wywołujemy www.gmail.com, musi to być metoda GET, skąd przeglądarka wie, że tej metody należy użyć?

Prawdziwe. Ponieważ jest to określone. Pierwsze żądanie jest takie jak zawsze - ZACZNIJ trochę początkowego kodu HTML, aby narysować interfejs użytkownika, a następnie albo go szturchaj i manipuluj nim na zawsze, albo uzyskaj inną stronę z innym skryptem, który szturcha i manipuluje i tworzy responsywny reaktywny interfejs użytkownika

Jak pokazują niektóre odpowiedzi, możemy tworzyć nowych użytkowników metodą DELETE, to rodzi pytanie o zamiar pojęcia w protokole http, ponieważ pod koniec dnia całkowicie zależy od serwerów, na jaką funkcję chcą mapować adres URL . Dlaczego klient powinien informować serwery, jakich metod użyć dla adresu URL.

Historia. Dziedzictwo. Możemy teoretycznie wyrzucić jutro wszystkie metody http - jesteśmy na poziomie zaawansowania programowania, w którym metody są przestarzałe, ponieważ adresy URL są przetwarzalne w takim stopniu, w jakim mogą być mechanizmem przełączania, który wskazuje serwerowi, w którym chcesz zapisać dane treść jako robocza wiadomość e-mail lub usuń wersję roboczą - na serwerze nie ma pliku / email / draft / save / 1234 - serwer jest zaprogramowany do oddzielania tego adresu URL i wiedzieć, co zrobić z treścią ciała - zapisz jest to robocza wiadomość e-mail pod identyfikatorem 1234

Z pewnością można więc zrezygnować z metod, z wyjątkiem ogromnej wagi starszej kompatybilności, która wyrosła wokół nich. Lepiej jest po prostu użyć ich do tego, czego potrzebujesz, ale w dużej mierze je zignorować i zamiast tego użyć wszystkiego, czego potrzebujesz, aby uruchomić swoją rzecz. Wciąż potrzebujemy metod tak określonych, ponieważ musisz pamiętać, że mają one znaczenie dla przeglądarki i serwera, na którym stworzyliśmy nasze aplikacje. Skrypt po stronie klienta chce używać podstawowej przeglądarki do wysyłania danych, musi użyć metody, która sprawi, że przeglądarka zrobi to, o co poprosi - prawdopodobnie POST, ponieważ GET pakuje wszystkie swoje zmienne informacje do adresu URL i ma limit długości na wielu serwerach. Klient chce od serwera długiej odpowiedzi - nie używaj HEAD, ponieważ nie powinien on mieć żadnych ciał odpowiedzi.

HTTP można traktować jako jeden szczególny przypadek ogólnych zasad zdalnego wywoływania procedury: mówisz serwerowi, czego chcesz, za pomocą pola zmiennej w żądaniu, serwer odpowiada odpowiednio. Do tej pory, ze względu na złożoną interaktywność „Web 2.0”, te same funkcje są wyświetlane w każdym polu żądania: adres URL, nagłówki, treść - a każdy serwer i aplikacja rozumie je na swój sposób. Jednak pierwotnie sieć była prostsza, korzystała ze statycznych stron i uważano, że metody HTTP zapewniają wystarczający poziom interaktywności. Warto zauważyć, że HTTP ma wiele metod, które są używane rzadko, jeśli w ogóle, a niektóre z nich widzą światło tylko dzięki REST. Np. PUT i DELETE były konające przed REST, a TRACE i PATCH są nadal niewidoczne. Na wynos jest to, że model RPC protokołu HTTP nie

REST zrobił dokładnie odwrotność tego, co proponujesz, zauważając, że metody HTTP obsługują typowe przypadki użycia CRUD większości aplikacji, jeśli PUT i DELETE zostaną przywrócone.

Należy również pamiętać, że do metod HTTP przypisano im semantykę, które są honorowane przez przeglądarki i oprogramowanie pośrednie, takie jak serwery proxy: żądania POST, PUT, DELETE i PATCH mogą mieć skutki uboczne i prawdopodobnie nie będą idempotentne, więc aplikacje klienckie i oprogramowanie pośrednie zachowują ostrożność aby nie uruchamiać tych żądań bez wyraźnego działania ze strony użytkownika. W praktyce źle zaprojektowane aplikacje internetowe korzystały z GET do niebezpiecznych działań, a np . Moduł wstępny Google Web Accelerator powodował problemy, usuwając wiele danych z takich witryn , więc jego wersja beta została zawieszona wkrótce po uruchomieniu.

Tak więc, aby odpowiedzieć na pytanie „czy możemy”: jasne, wystarczy uzgodnić protokół, który powie aplikacji serwerowej, jakie działanie chcesz wykonać, a następnie umieścisz argumenty gdzieś w adresie URL / treści - takie jak element docelowy dla akcji. Zestaw działań jest ograniczony tylko przez określone aplikacje, więc potrzebujesz rozszerzalnego protokołu. Musisz jednak poinformować aplikacje klienckie, które żądania są bezpieczne, i prawdopodobnie wziąć pod uwagę inne niuanse, takie jak kontrola pamięci podręcznej.

Z mojego osobistego punktu widzenia jako programisty, może znacznie ułatwić tworzenie punktów końcowych interfejsu API. Na przykład, jeśli napiszę kontroler, który zarządza produktami na stronie internetowej, mogę użyć tego samego adresu URL do wykonania wielu różnych operacji.

Przykłady:

GET https://example.com/api/products/1234

Spowoduje to pobranie szczegółów produktu 1234.

POST https://example.com/api/products/1234

Spowoduje to utworzenie produktu o identyfikatorze 1234 z wykorzystaniem danych w treści żądania.

PUT https://example.com/api/products/1234

Spowoduje to zaktualizowanie produktu 1234 o dane w treści żądania.

DELETE https://example.com/api/products/1234

Spowoduje to usunięcie produktu o identyfikatorze 1234.

Mógłbym stworzyć różne punkty końcowe dla każdej operacji, ale skomplikowałoby to proces i uczyniłoby go mniej zrozumiałym dla innych programistów.

Czego potrzebują metody takie jak GET i POST w protokole HTTP?

Wygląda na to, że zapomniałeś dawnych czasów, kiedy serwery HTTP były tam tylko po to, by obsługiwać pliki ; brak uruchamiania skryptu, CGI lub tworzenie dynamicznej zawartości tego rodzaju.

Te metody żądania są proste standaryzowany zestaw czasowników na co zrobić z tymi plikami ...

• GET oznacza pobieranie
• HEAD oznacza uzyskanie informacji o
• PUT oznacza przesyłanie
• USUŃ oznacza usuń
• POST oznacza wysyłanie danych do
• OPCJE oznacza , że powiedz mi, co mogę zrobić

W dniu HTTP / 0.9, prośba linia jest jedyną rzeczą w nodze żądania protokołu; brak nagłówków żądań, brak nagłówków odpowiedzi. Po prostu piszesz , naciskasz , serwer zwróci treść odpowiedzi (tj. Treść HTML) i dobrze, dziękuję pa (tj. Zamknij połączenie).GET /somefileEnter

Jeśli chciałbyś tylko zapytać, dlaczego został zaprojektowany w ten sposób ? Moja odpowiedź brzmi, ponieważ pierwotnie został napisany w celu obsługi tego rodzaju wymiany treści, która istniała wtedy , tj. Udostępniania statycznych plików HTML na żądanie użytkowników.

Jeśli jednak chciałbyś zapytać o sposób traktowania tej semantyki we współczesnym serwerze aplikacji ...

Czy nie możemy zaimplementować protokołu HTTP, używając tylko treści żądania i odpowiedzi?

Czy wdrożenie różnych metod HTTP jest naprawdę potrzebne?

Moja odpowiedź brzmi: rób wszystko, co chcesz, ale pamiętaj, że nie powinieneś implementować logiki aplikacji w sposób, który przeczy oczekiwaniom protokołu : oczekiwania takie jak GET nie powinny zmieniać danych (lub bardzo luźno, mieć przynajmniej idempotentny wynik ), HEAD powinien mieć taki sam wynik jak GET, ale bez treści odpowiedzi, PUT powinien udostępnić treść docelowego URI (jeśli się powiedzie).

Jeśli postępujesz wbrew oczekiwaniom bez uważnego rozważenia ich konsekwencji , mogą się zdarzyć różne nieprzyjemne rzeczy, takie jak ...

• Gdy podłączysz metodę GET do przesyłania danych, serwer może wypluć ci w twarz błąd 414 „ URI Too Long ”.
• Gdy podłączysz metodę GET do użycia modyfikacji danych, zauważysz, że modyfikacja czasami nie przechodzi, gdy użytkownik stoi za buforującym serwerem proxy, lub nieoczekiwane modyfikacje miałyby miejsce, gdy użytkownik przywołał adres URL z zakładki (lub gdy osiągną go roboty indeksujące) .
• Gdy zareagujesz nieprawidłowo na metodę HEAD, zauważysz, że Twoje narzędzia do automatycznego sprawdzania witryny (np. wget --spider) Płacą za kaucję w Twojej witrynie.
• Gdy podłączysz metodę POST do pobierania zawartości, zauważysz, że zakładka, a nawet wpisanie adresu URL w przeglądarce nie zadziała.
• I wiele więcej...

„ Początkujący zna zasady, ale weterani znają wyjątki ”.

W każdym razie może się okazać, że znajdziesz jakieś usprawiedliwione wymówki, które są sprzeczne z niektórymi zasadami dotyczącymi niektórych wąskich przypadków użycia; ale pamiętaj o przeprowadzeniu badań i rozważeniu wszystkich możliwości. W przeciwnym razie skończysz na osiowaniu interoperacyjności i zrujnowaniu „doświadczeń użytkownika”.

Nie ma gwarancji, że użytkownicy zawsze używają najnowszego błyszczącego wdrożenia głównych klientów / agentów użytkowników znanych marek. Mogą używać lokalnej marki, która jest dostosowana do ich potrzeb (w tym mnie), niestandardowej, którą zamówili w sąsiednim sklepie specjalistycznym lub vintage, którą wykopali z magazynu. Mimo to wszystkie witryny nadal powinny zapewniać rozsądną obsługę. To jest powód, dla którego mamy standardy.

Nieostrożne łamanie standardów oznacza również, że dyskryminujesz użytkowników.

Prawdą jest, że teoretycznie moglibyśmy użyć tego miejsca i to by było trochę pracy. Niektóre programy używają nawet GET z treścią żądania (patrzę na ciebie elasticsearch / kibana). To oczywiście jest straszne.

Najważniejszym powodem jest to, że różne metody mają różną semantykę. Niektóre są bezpieczne, niektóre są idempotentne. Niektóre są oba. Zobacz, które są które

Jest to ważne np. Podczas interakcji z innymi aplikacjami. Punkty końcowe GET nie powinny mieć skutków ubocznych. Jest to ważne, gdy Google indeksuje twoją stronę. PUT ma być idempotentny, co oznacza, że ​​klient może spróbować ponownie w przypadku awarii. Nie dotyczy to POST, dlaczego przeglądarki muszą mieć brzydkie pole potwierdzenia, jeśli naciśniesz f5 na żądanie postu.

Zobacz, co może się zdarzyć, jeśli użyjesz GET tam, gdzie powinieneś był użyć POST

Możesz również myśleć o GET, POST itp. Jako przeciążeniu tej samej funkcji, a nawet o pobieraniu i ustawianiu.

GET_MyVar() nie przyjmie parametrów wejściowych (zwanych również treścią żądania), ale coś zwraca.

POST_MyVar(string blah)robi coś z danymi wejściowymi (ponownie w treści żądania) i może coś zwrócić. (Musi również zwrócić kod odpowiedzi, abyśmy wiedzieli, że funkcja została uruchomiona !!)

DELETE_MyVar() Prawdopodobnie nic też nie bierze i oczekuje się, że coś usunie.

Tak, moglibyśmy to wszystko wdrożyć:
MyVar(string Action, string? blah)

W ten sposób możemy zaakceptować tylko jedno połączenie, a następnie wybrać, co zrobić na podstawie innego parametru.

Ale jedną z zalet tego podejścia jest to, że pozwala przeglądarkom i serwerom zoptymalizować sposób działania tych rzeczy. Na przykład serwer może chcieć zablokować wszystkie żądania gdzie Action==DELETE. Może przeglądarki chcą buforować rzeczy, w których Action==GET.jeśli nie, to w każdej funkcji musielibyśmy pisaćif (Action==Delete) {return AngryFace}

Nie ma wymogu wdrażania wszystkiego dokładnie zgodnie z protokołem, ale protokół jest w zasadzie zbiorem reguł, których wszyscy postanowiliśmy przestrzegać. W ten sposób mogę łatwo odgadnąć, co zrobi Twoja witryna, nawet jeśli nie widziałem serwera!

Metody HTTP służą różnym celom. Zasadniczo GETsłuży do pobierania i POSTprzesyłania.

Jedynym sposobem zaimplementowania części protokołu HTTP przy użyciu tylko treści żądania i treści odpowiedzi byłoby wdrożenie POST. GETnie ma treści żądania. Ma tylko samą prośbę z nagłówkami, ale nie ma treści. To tylko prośba o dokument do pobrania. POSTzawiera zarówno treść żądania (przesyłanie pliku), jak i treść odpowiedzi (dokument pokazujący wynik).

Czy mógłbyś po prostu wdrożyć POSTi zrobić? Nie, jeśli chcesz, aby Twoja witryna była dostępna w standardowych przeglądarkach. Domyślny typ żądania wysyłanego przez przeglądarki to GET. POSTżądania są zwykle wysyłane tylko wtedy, gdy formularze na stronach internetowych są przesyłane lub do połączeń AJAX. Tylko jeśli ten konkretny serwer był używany tylko do wywołań AJAX, a nie do stron widocznych dla użytkowników, możesz być w stanie uciec POSTtylko.

Przeglądarki czasami wysyłają również HEADprośby o sprawdzenie, czy dokument zmienił się od czasu ostatniego pobrania, dlatego wskazane jest, aby to przynajmniej zaimplementować.

W każdym razie nie ma dobrego powodu, aby zaimplementować serwer WWW dla swojej witryny od zera. Protokół HTTP jest skomplikowany. Oprócz różnych metod należy również zaimplementować potokowanie i żądania porcji. O wiele łatwiej jest zbudować aplikację internetową na serwerze takim jak Apache, Nginx lub IIS, który obsługuje protokół HTTP za Ciebie. Wspominasz o serwletach, więc może powinieneś użyć serwerów WWW Tomcat lub JBoss, które obsługują serwlety.

Masz rację, moglibyśmy to zrobić, GET, POST, PUT itp. To tylko historyczne konwencje, gdybym miał swój sposób, HTTP zostałby zastąpiony tylko metodą POST i niczym innym, chociaż muszę przyznać, że wyeliminowanie GET byłoby ogromnym przedsięwzięciem, tego nie da się zrobić, koń już na to wpadł

Proponowany protokół byłby znacznie mniej bezpieczny przed hakerami.

Istnieje powód, dla którego strony internetowe odeszły od przechowywania informacji o zmiennych i takich w adresie URL, i ten powód jest prosty: daje atakującym bardzo prosty sposób na atakowanie twojego systemu. Obserwując informacje o adresie URL w postaci zwykłego tekstu, mogą określić sposób, w jaki konstruowane są dane wysyłane na serwer sieciowy; mogą następnie wykorzystać te informacje do przeprowadzenia ataku na Twój serwer przy użyciu specjalnie skonstruowanego adresu URL, który pozwala im wstrzykiwać złośliwy kod lub dane na Twój serwer.