Was ist der Bedarf an Methoden wie GET und POST im HTTP-Protokoll?

Können wir das HTTP-Protokoll nicht nur mit einem Anforderungs- und einem Antworttext implementieren?

Beispielsweise enthält die URL eine Anfrage, die einer Funktion zugeordnet wird, die von der Programmiersprache auf der Serverseite abhängt, beispielsweise einem Servlet. Als Antwort werden HTML- und JavaScript-Antworten gesendet.

Warum kennt das HTTP-Protokoll Methoden?

Aus den Antworten ergibt sich ein Gefühl dafür, warum es ein Konzept von Methoden gibt. Dies führt zu einer weiteren verwandten Frage:

Beispielsweise werden in Google Mail beim Erstellen eines Links die PUT / POST-Anforderung und die Daten gesendet. Wie erfährt der Browser, welche Methode er anwenden soll? Enthält die vom Server gesendete Google Mail-Seite den Methodennamen, der beim Aufrufen der Google Mail-Erstellungsanforderung verwendet werden soll? Wenn wir www.gmail.com aufrufen, muss die GET-Methode verwendet werden. Woher weiß der Browser, dass diese Methode zu verwenden ist?

PS : Ich habe nicht genug Credits, um Antworten zu kommentieren, daher kann ich nicht viele Fragen kommentieren, die von Leuten gestellt wurden, die mit der Absicht hinter dieser Frage zu tun haben.

Wie einige Antworten zeigen, können wir mit der DELETE-Methode neue Benutzer erstellen. Dies wirft dann die Frage auf, welche Absicht hinter den Methoden des http-Protokolls steckt, denn letztendlich hängt es völlig von den Servern ab, welcher Funktion sie eine URL zuordnen möchten . Warum sollte der Client den Servern mitteilen, welche Methoden für eine URL verwendet werden sollen?

Bitte beachten Sie, dass sich die Frage geändert / geklärt hat, seit diese Antwort zum ersten Mal geschrieben wurde. Eine weitere Antwort auf die letzte Wiederholung der Frage folgt nach der zweiten horizontalen Regel

Was ist der Bedarf an Methoden wie GET und POST im HTTP-Protokoll?

Sie bilden, zusammen mit einigen anderen Dingen wie Header-Formaten, Regeln für die Trennung von Headern und Body, die Grundlage des HTTP-Protokolls

Können wir das HTTP-Protokoll nicht nur mit einem Anforderungs- und einem Antworttext implementieren?

Nein, denn was auch immer Sie erstellt haben, wäre nicht das HTTP-Protokoll

Beispielsweise enthält die URL eine Anfrage, die einer Funktion zugeordnet wird, die von der Programmiersprache auf der Serverseite abhängt, beispielsweise einem Servlet. Als Antwort werden HTML- und JavaScript-Antworten gesendet.

Herzlichen Glückwunsch, Sie haben gerade ein neues Protokoll erfunden! Wenn Sie nun einen Standardkörper einrichten möchten, um ihn zu betreiben, zu warten, zu entwickeln usw., könnte er eines Tages HTTP überholen

Ich schätze, das ist ein bisschen verwunderlich, aber das Internet, TCP / IP oder die Kommunikation zwischen Servern und Clients haben nichts Magisches an sich. Sie stellen eine Verbindung her und senden ein paar Worte, um ein Gespräch zu führen. Die Konversation muss wirklich an beiden Enden einer bestätigten Spezifikation entsprechen, wenn die Anforderungen verstanden und vernünftige Antworten geliefert werden sollen. Dies unterscheidet sich nicht von jedem Dialog auf der Welt. Sie sprechen Englisch, Ihr Nachbar spricht Chinesisch. Hoffentlich reicht es aus, wenn Sie mit der Hand winken, zeigen und mit der Faust zittern, um Ihre Botschaft zu übermitteln, dass er sein Auto nicht vor Ihrem Haus parken soll.

Wieder im Internet, wenn Sie einen Socket zu einem HTTP-kompatiblen Webserver öffnen und Folgendes senden:

EHLO
AUTH LOGIN

(Der Beginn einer SMTP-E-Mail-Übertragung) Dann erhalten Sie keine vernünftige Antwort. Sie könnten den perfektesten SMTP-kompatiblen Client erstellen, aber Ihr Webserver wird nicht mit ihm sprechen, da es bei dieser Konversation nur um das gemeinsame Protokoll geht - kein gemeinsames Protokoll, keine Freude.

Aus diesem Grund können Sie das HTTP-Protokoll nicht implementieren, ohne das HTTP-Protokoll zu implementieren. Wenn das, was Sie schreiben, nicht dem Protokoll entspricht, ist es einfach nicht das Protokoll - es ist etwas anderes, und es funktioniert nicht wie im Protokoll angegeben

Wenn wir für einen Moment mit Ihrem Beispiel rennen; Wenn der Client eine Verbindung herstellt und nur etwas angibt, das aussieht wie eine URL. Und der Server versteht es und sendet nur etwas, das aussieht wie HTML / JS (eine Webseite), dann könnte es funktionieren. Was hast du allerdings gespart? Ein paar Bytes, wenn Sie nicht GET sagen? Nur ein paar mehr zum Löschen dieser lästigen Header. Der Server hat auch einige gespeichert - aber was ist, wenn Sie nicht herausfinden können, was er Ihnen gesendet hat? Was ist, wenn Sie nach einer URL gefragt haben, die mit JPEG endet und Ihnen einige Bytes sendet, die ein Bild ergeben, aber in PNG? Eine unvollständige PNG dazu. Wenn wir nur einen Header hätten, der angibt, wie viele Bytes er enthältzu senden, dann würden wir wissen, ob die Anzahl der Bytes, die wir empfangen haben, tatsächlich die gesamte Datei ist oder nicht. Was passiert, wenn der Server die Antwort gezippt hat, um Bandbreite zu sparen, Ihnen dies aber nicht mitgeteilt hat? Sie werden beträchtliche Rechenleistung aufwenden, um herauszufinden, was es gesendet hat.

Letztendlich brauchen wir Metainformationen - Informationen über Informationen; wir brauchen Überschriften; Wir brauchen Dateien, die Namen, Erweiterungen und Erstellungsdaten haben. Wir brauchen Leute, die Geburtstage haben, um bitte und danke zu sagen usw. - die Welt ist voll von Protokollen und Informationen über den Kontext, damit wir uns nicht die ganze Zeit hinsetzen und alles von Grund auf neu ausarbeiten müssen. Es kostet ein bisschen Speicherplatz, aber es lohnt sich leicht

Ist die Implementierung verschiedener HTTP-Methoden wirklich erforderlich?

Man muss wohl nicht das gesamte angegebene Protokoll implementieren, und dies gilt normalerweise für alles. Ich kenne nicht jedes Wort in der englischen Sprache. Mein chinesischer Nachbar ist ebenfalls Softwareentwickler, aber in einer anderen Branche und er kennt nicht einmal die Chinesen für einige der in meiner Branche verwendeten Begriffe, geschweige denn die Engländer. Das Gute ist jedoch, dass wir beide ein Dokument über die Implementierung von HTTP abholen können, er den Server und ich den Client in verschiedenen Programmiersprachen auf verschiedenen Architekturen schreiben können und sie weiterhin funktionieren, weil sie sich an das Protokoll halten

Es kann durchaus vorkommen, dass keiner Ihrer Benutzer eine andere Anforderung als eine GET-Anforderung ausgibt, keine dauerhaften Verbindungen verwendet, andere als JSON als Textkörper sendet oder andere als text / plain akzeptiert, damit Sie dies tun können Schreiben Sie einen wirklich reduzierten Webserver, der nur die sehr begrenzten Anforderungen des Client-Browsers erfüllt. Sie konnten sich jedoch nicht einfach willkürlich entscheiden, die Grundregeln aufzuheben, die bewirken, dass "ein Teil des Textes über einen Socket weitergeleitet wird", was HTTP ist. Sie können die Grundidee, dass die Anfrage eine Zeichenkette sein wird, nicht loswerden:

VERB URL VERSION
header: value

maybe_body

Die Antwort enthält eine Version, einen Statuscode und möglicherweise Überschriften. Wenn Sie irgendetwas davon ändern - es ist nicht mehr HTTP -, ist es etwas anderes und funktioniert nur mit etwas, das entworfen wurde, um es zu verstehen. HTTP entspricht diesen Definitionen. Wenn Sie es also implementieren möchten, müssen Sie den Definitionen folgen

Aktualisieren

Ihre Frage hat sich etwas weiterentwickelt. Hier ist eine Antwort auf Ihre Frage:

Warum kennt das HTTP-Protokoll Methoden?

Historisch gesehen muss man erkennen, dass die Dinge viel unflexibler in ihrem Design und ihrer Implementierung waren, selbst in dem Maße, wie es kein Scripting gab und sogar die Vorstellung, dass Seiten dynamisch sein könnten, im laufenden Betrieb im Speicher generiert und stattdessen den Socket runtergeschoben werden Es gab keine statische Datei auf der Festplatte, die vom Client angefordert und vom Socket gelesen und heruntergeladen wurde. Als solches wäre das sehr frühe Web, das sich um den Begriff der statischen Seiten drehte, die Links zu anderen Seiten enthielten, alle Seiten auf der Festplatte und Navigation gewesen, wenn das Terminal meistens GET-Anfragen für Seiten an URLs gestellt hätte, die der Server abbilden könnte die URL zu einer Datei auf der Festplatte und senden Sie es. Es gab auch den Gedanken, dass sich das Netz von Dokumenten, die miteinander und mit anderen verknüpft sind, weiterentwickeln sollte.

Das gibt einen historischen Kontext für die Methoden - früher war die URL das unflexible Bit und bezog sich vereinfacht auf Seiten auf der Festplatte, sodass die Methode nützlich war, da der Client beschreiben konnte, welche Absichten sie für die Datei und den Server hatte Verarbeiten Sie die Methode auf unterschiedliche Weise. Es gab eigentlich keine Vorstellung davon, dass URLs virtuell sind oder zum Umschalten oder Zuordnen in der ursprünglichen Vision eines Hypertext-Webs (und es war wirklich nur Text) verwendet werden

Ich beabsichtige nicht, dass diese Antwort eine Dokumentation der historischen Aufzeichnungen mit Daten und zitierten Referenzen darüber ist, wann sich die Dinge zu ändern begannen - dafür kann man wahrscheinlich Wikipedia lesen -, aber es ist ausreichend zu sagen, dass im Laufe der Zeit der Wunsch nach dem Das Web wird immer dynamischer und an jedem Ende der Server-Client-Verbindung werden die Möglichkeiten erweitert, ein reichhaltiges Multimedia-Erlebnis zu schaffen. Die Browser unterstützten eine große Anzahl von Tags für die Formatierung von Inhalten, wobei jeder einzelne nach unerlässlichen Funktionen für die Medienvielfalt und neuen Möglichkeiten suchte, die Dinge elegant aussehen zu lassen.

Auf Client-Seite kamen Skripte, Plugins und Browser-Erweiterungen, die den Browser zu einem mächtigen Kraftpaket für alles machen sollten. Auf der Serverseite war die aktive Generierung von Inhalten auf der Basis von Algorithmen oder Datenbankdaten der große Schub, und sie entwickelt sich in dem Maße weiter, in dem sich wahrscheinlich nur noch wenige Dateien auf der Festplatte befinden. Wir behalten also eine Bild- oder Skriptdatei als Datei bei Der Webserver und der Browser holen es sich, aber zunehmend sind die Bilder, die der Browser anzeigt, und die Skripte, die er ausführt, keine Dateien, die Sie in Ihrem Datei-Explorer öffnen können, sondern generierte Inhalte, die die Ausgabe eines Kompilierungsprozesses sind, der bei Bedarf ausgeführt wird , SVG, das beschreibt, wie Pixel anstatt eines Bitmap-Arrays von Pixeln gezeichnet werden, oder JavaScript, das von einer übergeordneten Skriptform wie TypeScript ausgegeben wurde

Bei der Erstellung moderner Multi-Megabyte-Seiten ist wahrscheinlich nur ein Bruchteil davon jetzt fester Inhalt auf einer Festplatte. Datenbankdaten werden formatiert und in HTML-Form gebracht, die der Browser verwendet, und vom Server als Reaktion auf mehrere verschiedene Programmierroutinen, auf die die URL in irgendeiner Weise verweist

Ich erwähnte in den Kommentaren zu der Frage, dass es ein bisschen wie ein voller Kreis ist. Damals, als Computer Hunderttausende kosteten und Räume füllten, war es üblich, dass mehrere Benutzer über Hunderte von dummen Terminals den einen sehr leistungsstarken zentralen Großrechner nutzten - eine Tastatur und eine Maus, ein grüner Bildschirm, etwas Text einschicken, etwas abrufen Text aus. Im Laufe der Zeit, als die Rechenleistung zunahm und die Preise sanken, wurden die Desktop-Computer leistungsstärker als bei früheren Mainframes und die Möglichkeit, leistungsstarke Apps lokal auszuführen, wurde das Mainframe-Modell veraltet. Es ging jedoch nie verloren, da sich die Dinge nur in die entgegengesetzte Richtung entwickelten und zu einem zentralen Server zurückkehrten, der den größten Teil der nützlichen App-Funktionalität und hundert Client-Computer bereitstellte, auf denen außer dem Zeichnen auf dem Bildschirm nur sehr wenig zu tun war. Senden und Empfangen von Daten zum / vom Server. In der Zwischenzeit, in der Ihr Computer intelligent genug war, um eine eigene Kopie von Word und Outlook gleichzeitig auszuführen, wurde Office Online wieder aktiviert, in dem Ihr Browser ein Gerät zum Zeichnen von Bildern auf dem Bildschirm und Bearbeiten des Dokuments / der E-Mail ist. Das Schreiben als eine Sache, die auf dem Server lebt, dort gespeichert, gesendet und mit anderen Benutzern geteilt wird, unter der Annahme, dass der Browser nur eine Shell ist, die zu jeder Zeit eine Teilansicht dieser Sache bietet, die woanders lebt

Aus den Antworten ergibt sich ein Gefühl dafür, warum es ein Konzept von Methoden gibt. Dies führt zu einer weiteren verwandten Frage:

Beispielsweise werden in Google Mail beim Erstellen eines Links die PUT / POST-Anforderung und die Daten gesendet. Wie erfährt der Browser, welche Methode er anwenden soll?

Standardmäßig wird GET verwendet, gemäß Konvention / Spezifikation, da dies gesetzlich vorgeschrieben ist, wenn Sie eine URL eingeben und die Eingabetaste drücken

Enthält die vom Server gesendete Google Mail-Seite den Methodennamen, der beim Aufrufen der Google Mail-Erstellungsanforderung verwendet werden soll?

Dies ist eine der Schlüsselsachen, auf die ich in den obigen Kommentaren hinweise. Im modernen Web geht es nicht einmal mehr um Seiten. Sobald die Seiten Dateien auf der Festplatte waren, wurde diese vom Browser abgerufen. Dann wurden sie zu Seiten, die überwiegend dynamisch generiert wurden, indem Daten in eine Vorlage eingefügt wurden. Es ging jedoch immer noch um den Prozess "Neue Seite vom Server anfordern, Seite abrufen, Seite anzeigen". Das Auswechseln der Seiten wurde wirklich raffiniert; Sie haben nicht gesehen, wie sie geladen und in der Größe verändert wurden und ihr Layout verschoben wurde, so dass es flüssiger wurde, aber es war immer noch der Browser, der eine ganze Seite oder einen Teil einer Seite durch eine andere ersetzte

Die moderne Art, Dinge zu tun, ist mit einer einzigen Anwendung. Der Browser hat ein Dokument im Speicher, das auf eine bestimmte Art und Weise angezeigt wird, Skriptaufrufe an thebservr und ein paar Informationen zurückerhält und das Dokument so bearbeitet, dass ein Teil der Seite sich visuell ändert, um die neuen Informationen anzuzeigen - das Ganze läuft ohne der Browser lädt jemals eine andere neue Seite; Es ist einfach eine Benutzeroberfläche geworden, in der Teile wie bei einer typischen Client-App wie Word oder Outlook aktualisiert werden. Neue Elemente werden über anderen Elementen angezeigt und können durch das Simulieren von Dialogfenstern usw. gezogen werden. All dies Ist das Browser-Skriptmodul, das Anforderungen mit der vom Entwickler gewünschten http-Methode sendet, Daten zurückruft und auf das vom Browser gezeichnete Dokument zugreift. Sie können sich vorstellen, dass der moderne Browser ein brillantes Gerät ist, das so etwas wie ein gesamtes Betriebssystem oder ein virtueller Computer ist. Ein programmierbares Gerät, das eine ziemlich standardisierte Methode zum Zeichnen von Objekten auf dem Bildschirm, zum Abspielen von Tönen, zum Erfassen von Benutzereingaben und zum Senden zur Verarbeitung bietet. Alles, was Sie tun müssen, um Ihre Benutzeroberfläche zeichnen zu lassen, ist, sie mit etwas HTML / CSS zu versehen, mit dem eine Benutzeroberfläche erstellt wird, und dann das HTML ständig zu optimieren, damit der Browser ändert, was er zeichnet. Zum Teufel, die Leute sind es so gewohnt, dass eine einzelne Seiten-App die URL programmgesteuert ändert, obwohl gerade keine Navigation (Anforderung ganz neuer Seiten) ausgeführt wird Alles, was Sie tun müssen, um Ihre Benutzeroberfläche zeichnen zu lassen, ist, sie mit etwas HTML / CSS zu versehen, mit dem eine Benutzeroberfläche erstellt wird, und dann das HTML ständig zu optimieren, damit der Browser ändert, was er zeichnet. Zum Teufel, die Leute sind es so gewohnt, dass eine einzelne Seiten-App die URL programmgesteuert ändert, obwohl gerade keine Navigation (Anforderung ganz neuer Seiten) ausgeführt wird Alles, was Sie tun müssen, um Ihre Benutzeroberfläche zeichnen zu lassen, ist, sie mit etwas HTML / CSS zu versehen, mit dem eine Benutzeroberfläche erstellt wird, und dann das HTML ständig zu optimieren, damit der Browser ändert, was er zeichnet. Zum Teufel, die Leute sind es so gewohnt, dass eine einzelne Seiten-App die URL programmgesteuert ändert, obwohl gerade keine Navigation (Anforderung ganz neuer Seiten) ausgeführt wird

Wenn wir www.gmail.com aufrufen, muss die GET-Methode verwendet werden. Woher weiß der Browser, dass diese Methode zu verwenden ist?

Wahr. Weil es spezifiziert ist. Die erste Anforderung ist, wie es in der Vergangenheit immer der Fall war, HTML-Code zu erhalten, um eine Benutzeroberfläche zu zeichnen, sie dann entweder für immer anzustupsen und zu manipulieren oder eine andere Seite mit einem anderen Skript zu erhalten, das die Benutzeroberfläche anstößt und manipuliert und eine reaktive Benutzeroberfläche erstellt

Wie einige Antworten zeigen, können wir mit der DELETE-Methode neue Benutzer erstellen. Dies wirft dann die Frage auf, welche Absicht hinter den Methoden des http-Protokolls steckt, denn letztendlich hängt es völlig von den Servern ab, welcher Funktion sie eine URL zuordnen möchten . Warum sollte der Client den Servern mitteilen, welche Methoden für eine URL verwendet werden sollen?

Geschichte. Erbe. Theoretisch könnten wir morgen alle http-Methoden wegwerfen. Wir befinden uns auf einem Programmierniveau, bei dem Methoden veraltet sind, da URLs so weit verarbeitet werden können, dass sie dem Server als Vermittlungsmechanismus anzeigen, auf dem Sie die Daten speichern möchten den Körper als Entwurf einer E-Mail oder einen Entwurf löschen - es befindet sich keine Datei / emails / draft / save / 1234 auf dem Server - der Server ist so programmiert, dass er diese URL auseinander nimmt und weiß, was mit dem Körperdatenspeicher zu tun ist es als Entwurf einer E-Mail unter der ID 1234

Es ist also durchaus möglich, Methoden abzuschaffen, abgesehen von der enormen Menge an Kompatibilität, die um sie herum entstanden ist. Es ist besser, sie nur für das zu verwenden, was Sie brauchen, aber sie weitgehend zu ignorieren und stattdessen alles zu verwenden, was Sie brauchen, um Ihr Ding zum Laufen zu bringen. Wir brauchen immer noch Methoden, da Sie sich daran erinnern müssen, dass sie etwas für den Browser und den Server bedeuten, auf dem wir unsere Apps erstellt haben. Das clientseitige Skript möchte den zugrunde liegenden Browser zum Senden von Daten verwenden. Es muss eine Methode verwenden, mit der der Browser die angeforderten Anforderungen erfüllt - wahrscheinlich ein POST, da GET alle variablen Informationen in die URL packt und die Länge begrenzt ist in vielen Servern. Der Client möchte eine lange Antwort vom Server - verwenden Sie keinen HEAD, da er überhaupt keine Antwortkörper haben soll.

HTTP kann als ein spezifischer Fall allgemeiner Prinzipien des Remote Procedure Call angesehen werden: Wenn Sie dem Server mitteilen, was Sie möchten, und die Anforderung ein variables Feld enthält, reagiert der Server entsprechend. Aufgrund der komplexen Interaktivität von "Web 2.0" werden jetzt in jedem Feld der Anforderung dieselben Funktionen angezeigt: URL, Header, Body - und jeder App-Server und jede App verstehen sie auf ihre Weise. Ursprünglich war das Web jedoch einfacher, es wurden statische Seiten verwendet, und es wurde davon ausgegangen, dass die HTTP-Methoden für den Grad der Interaktivität ausreichen würden. Bemerkenswerterweise gibt es in HTTP viele Methoden, die, wenn überhaupt, nur selten verwendet werden und von denen einige dank REST nur das Licht sehen. ZB waren PUT und DELETE vor REST moribund, und TRACE und PATCH sind afaik noch unsichtbar. Zum Mitnehmen ist, dass das HTTP-Modell von RPC nicht "

REST tat genau das Gegenteil von dem, was Sie vorschlagen, indem es feststellte, dass die HTTP-Methoden die typischen CRUD-Anwendungsfälle der meisten Apps bedienen, wenn PUT und DELETE zurückgebracht werden.

Beachten Sie auch, dass den HTTP-Methoden eine Semantik zugewiesen ist, die von Browsern und Middleware wie Proxy-Servern berücksichtigt wird: POST-, PUT-, DELETE- und PATCH-Anforderungen können Nebenwirkungen haben und sind wahrscheinlich nicht idempotent, sodass clientseitige Apps und Middleware Vorsicht walten lassen diese Anforderungen nicht ohne ausdrückliche Handlung des Benutzers auszulösen. In der Praxis verwendeten schlecht gestaltete Web-Apps GET für nicht sichere Aktionen, und z. B. verursachte der Prefetcher von Google Web Accelerator Probleme, indem er Datenbündel auf solchen Websites löschte. Daher wurde die Betaversion kurz nach dem Start ausgesetzt.

Zur Beantwortung der Frage "Können wir" müssen Sie sich nur auf ein Protokoll einigen, das der Server-App mitteilt, welche Aktion Sie ausführen möchten, und dann die Argumente an einer beliebigen Stelle in die URL / den Text einfügen, z Zielelement für die Aktion. Die Reihe der Aktionen ist nur an bestimmte Apps gebunden, sodass Sie ein erweiterbares Protokoll benötigen. Sie müssen den Client-Apps jedoch mitteilen, welche Anforderungen sicher sind, und möglicherweise andere Nuancen berücksichtigen, z. B. die Cachesteuerung.

Aus meiner persönlichen Sicht als Entwickler kann dies das Erstellen von API-Endpunkten erheblich vereinfachen. Wenn ich zum Beispiel einen Controller schreibe, der Produkte auf einer Website verwaltet, kann ich dieselbe URL verwenden, um mehrere verschiedene Vorgänge auszuführen.

Beispiele:

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

Dadurch werden die Details von Produkt 1234 abgerufen.

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

Dadurch wird ein Produkt mit der ID 1234 unter Verwendung der Daten im Anforderungshauptteil erstellt.

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

Dadurch wird Produkt 1234 mit Daten im Anforderungshauptteil aktualisiert.

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

Dadurch wird ein Produkt mit der ID 1234 gelöscht.

Ich könnte für jede Operation unterschiedliche Endpunkte festlegen, aber das würde den Prozess verkomplizieren und ihn für andere Entwickler weniger verständlich machen.

Was ist der Bedarf an Methoden wie GET und POST im HTTP-Protokoll?

Es scheint, dass Sie die alten Zeiten vergessen haben, als HTTP-Server nur dazu da waren, Dateien bereitzustellen. Skript, CGI oder dynamische Inhalte dieser Art werden nicht ausgeführt.

Die Anforderungsmethoden sind standardisierte Verben, die beschreiben, was mit diesen Dateien zu tun ist ...

• GET bedeutet herunterladen
• HEAD bedeutet , Informationen zu erhalten
• PUT bedeutet Upload
• LÖSCHEN bedeutet entfernen
• POST bedeutet Daten senden an
• OPTIONEN bedeutet mir zu sagen, was ich tun könnte

Am Tag von HTTP / 0.9 ist die Anforderungszeile das einzige Element im Anforderungsabschnitt des Protokolls. Keine Anforderungsheader, keine Antwortheader. Geben Sie einfach ein GET /somefile, drücken Sie Enter, der Server gibt den Antworttext (dh HTML-Inhalt) zurück und okay, danke (dh die Verbindung wird geschlossen).

Wenn Sie nur fragen wollten , warum es so konzipiert wurde ? Meine Antwort ist, dass es ursprünglich geschrieben wurde , um die Art des Inhaltsaustauschs zu behandeln, der damals existierte , dh die Bereitstellung statischer HTML-Dateien auf Anforderung der Benutzer.

Wenn Sie sich jedoch fragen möchten, wie diese Semantik in modernen Anwendungsservern behandelt werden soll ...

Können wir das HTTP-Protokoll nicht nur mit einem Anforderungs- und einem Antworttext implementieren?

Ist die Implementierung verschiedener HTTP-Methoden wirklich erforderlich?

Meine Antwort lautet: Tun Sie, was immer Sie möchten, aber denken Sie daran, dass Sie die Anwendungslogik nicht auf eine Weise implementieren sollten , die den Erwartungen des Protokolls widerspricht : Erwartungen wie GET sollten Daten nicht ändern (oder sehr locker, zumindest idempotentes Ergebnis haben) ), HEAD sollte dasselbe Ergebnis haben wie GET, aber ohne Antworttext, PUT sollte den Inhalt der Ziel-URI verfügbar machen (falls erfolgreich).

Wenn Sie gegen die Erwartungen verstoßen , ohne die Auswirkungen sorgfältig abzuwägen , passieren verschiedene unangenehme Dinge, wie ...

• Wenn Sie die GET-Methode in die Verwendung der Datenübermittlung einweihen, zeigt der Server möglicherweise den Fehler 414 " URI Too Long " ( URI zu lang ) in Ihrem Gesicht an.
• Wenn Sie die GET-Methode in die Verwendung von Datenänderungen einarbeiten, werden Sie feststellen, dass Änderungen manchmal nicht erfolgreich sind, wenn sich der Benutzer hinter einem Caching-Proxy befindet, oder unerwartete Änderungen stattfinden, wenn der Benutzer die URL von einem Lesezeichen abruft (oder wenn Webcrawler darauf zugreifen). .
• Wenn Sie nicht ordnungsgemäß auf die HEAD-Methode reagieren, stellen Sie fest, dass Ihre Tools für die automatische Site-Überprüfung (z. B. wget --spider) nicht mehr auf Ihrer Site verfügbar sind.
• Wenn Sie die POST-Methode in den Download von Inhalten einbinden, werden Sie feststellen, dass Lesezeichen oder die Eingabe der URL in den Browser nicht funktionieren.
• Und viele mehr...

" Anfänger kennen Regeln, aber Veteranen kennen Ausnahmen. "

Wie auch immer, Sie könnten am Ende einige gültige Ausreden finden, um gegen einige der Regeln für einige enge Anwendungsfälle zu verstoßen. Aber stellen Sie sicher, dass Sie Ihre Recherche durchführen und alle Möglichkeiten in Betracht ziehen. Andernfalls wird die Interoperabilität beeinträchtigt und "Benutzererfahrungen" ruiniert.

Es gibt keine Garantie dafür, dass Benutzer immer das neueste, glänzende Rollout der von Ihnen getesteten Mainstream-Kunden / Benutzeragenten verwenden. Sie können eine lokale Marke verwenden, die auf ihre Bedürfnisse zugeschnitten ist (ich eingeschlossen), eine benutzerdefinierte Marke, die sie im Fachgeschäft nebenan bestellt haben, oder eine Vintage-Marke, die sie in einem Lagerraum ausgegraben haben. Trotz alledem wird von Ihren Websites ein angemessener Service erwartet. Das ist ein Grund, warum wir Standards haben.

Ein unachtsamer Verstoß gegen den Standard bedeutet auch, dass Sie Ihre Benutzer diskriminieren .

Theoretisch könnten wir es gebrauchen, überall hin zu kommen, und es würde irgendwie funktionieren. Einige Software benutzen sogar GET mit Request Body (ich schaue Dir Elasticsearch / Kibana an). Das ist natürlich eine schreckliche Sache.

Der wichtigste Grund ist, dass die verschiedenen Methoden unterschiedliche Semantiken haben. Einige sind sicher, andere sind idempotent. Manche sind beides. Sehen Sie, welche welche sind

Dies ist zB bei der Interaktion mit anderen Anwendungen wichtig. GET-Endpunkte dürfen keine Nebenwirkungen haben. Dies ist wichtig, wenn Google Ihre Seite durchsucht. PUT soll idempotent sein, was bedeutet, dass es dem Client freigestellt ist, es im Falle eines Fehlers erneut zu versuchen. Dies ist bei POST nicht der Fall, weshalb Browser ein hässliches Bestätigungsfeld haben müssen, wenn Sie bei einer Post-Anfrage die Taste f5 drücken.

Sehen Sie, was passieren kann, wenn Sie GET dort verwenden, wo Sie POST hätten verwenden sollen

Sie können sich GET, POST usw. auch als Überladungen derselben Funktion oder sogar als Get und Setter vorstellen.

GET_MyVar() Nimmt keinen Eingabeparameter (auch als Request Body bezeichnet), gibt aber etwas zurück.

POST_MyVar(string blah)Tut etwas mit der Eingabe (wieder der Anfragetext) und kann etwas zurückgeben. (Es muss auch mindestens ein Antwortcode zurückgegeben werden, damit wir wissen, dass die Funktion ausgeführt wurde !!)

DELETE_MyVar() Auch nimmt wohl nichts und wird voraussichtlich etwas löschen.

Ja, wir könnten alles implementieren mit:
MyVar(string Action, string? blah)

Auf diese Weise könnten wir nur einen Anruf annehmen und dann basierend auf einem anderen Parameter auswählen, was zu tun ist.

Ein Vorteil dieses Ansatzes ist jedoch, dass Browser und Server die Funktionsweise dieser Dinge optimieren können. Beispielsweise möchte der Server möglicherweise alle Anforderungen blockieren, bei denen Action==DELETE. Vielleicht möchten Browser Dinge zwischenspeichern, bei denen Action==GET.wir, wenn nicht, in jeder Funktion schreiben müsstenif (Action==Delete) {return AngryFace}

Es ist nicht erforderlich, alles genau gemäß dem Protokoll zu implementieren, aber das Protokoll besteht im Grunde aus einer Reihe von Regeln, die wir alle befolgen wollten. Auf diese Weise kann ich leicht erraten, was Ihre Website tun wird, auch wenn ich den Server nicht gesehen habe!

HTTP-Methoden dienen unterschiedlichen Zwecken. Im Allgemeinen GETgilt dies für Downloads und POSTfür Uploads.

Die einzige Möglichkeit, einen Teil des HTTP-Protokolls mit nur einem Anforderungs- und einem Antworttext zu implementieren, wäre die Implementierung POST. GEThat keinen Anfragetext. Es hat nur die Anfrage selbst mit Headern, aber keinen Body. Es ist nur eine Aufforderung zum Herunterladen eines Dokuments. POSThat sowohl den Anforderungshauptteil (den Datei-Upload) als auch einen Antworthauptteil (das Dokument, das das Ergebnis zeigt).

Könnten Sie also einfach implementieren POSTund fertig sein? Nicht, wenn Sie möchten, dass Ihre Website in Standardbrowsern verwendet werden kann. Der Standardanforderungstyp, den Browser senden, ist GET. POSTAnfragen werden normalerweise nur gesendet, wenn Formulare auf Webseiten gesendet werden oder für AJAX-Aufrufe. Nur wenn dieser bestimmte Server nur für AJAX-Aufrufe und nicht für für Benutzer sichtbare Seiten verwendet würde, könnten Sie möglicherweise POSTnur davonkommen .

Browser senden manchmal auch HEADAnfragen, um zu prüfen, ob sich ein Dokument seit dem letzten Herunterladen geändert hat. Daher ist es ratsam, dies zumindest ebenfalls zu implementieren.

In jedem Fall gibt es keinen guten Grund, einen Webserver für Ihre Site von Grund auf neu zu implementieren. Das HTTP-Protokoll ist kompliziert. Zusätzlich zu den verschiedenen Methoden müssten Sie auch Pipelining- und Chunk-Anforderungen implementieren. Es ist viel einfacher, Ihre Webanwendung auf einem Webserver wie Apache, Nginx oder IIS zu erstellen, der das HTTP-Protokoll für Sie verwaltet. Wenn Sie Servlets erwähnen, sollten Sie möglicherweise Tomcat- oder JBoss-Webserver verwenden, auf denen Servlets ausgeführt werden.

Sie haben Recht, wir könnten genau das tun. GET, POST, PUT usw. sind nur historische Konventionen, wenn ich so wäre, würde HTTP durch die reine POST-Methode ersetzt, und nichts anderes, obwohl ich zugeben muss, dass die Beseitigung von GET ein riesiges Unterfangen wäre. das geht nicht, das pferd hat das schon angeschraubt

Ihr vorgeschlagenes Protokoll wäre deutlich weniger sicher gegen Hacker.

Es gibt einen Grund, warum Websites Informationen über Variablen und dergleichen nicht mehr in der URL speichern, und dieser Grund ist einfach: Angreifer können auf sehr einfache Weise Ihr System angreifen. Durch Beobachtung der Klartext-URL-Informationen können sie bestimmen, wie die an Ihren Webserver gesendeten Daten aufgebaut sind. Anhand dieser Informationen können sie einen Angriff auf Ihren Server ausführen, indem sie eine speziell erstellte URL verwenden, mit der sie bösartigen Code oder Daten auf Ihren Server übertragen können.