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.