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

17

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?

user104656
quelle
Ja und nein. Ihre Frage kollidiert mit sich selbst, da Sie sagen, Sie möchten wissen, wie Sie HTTP-Anfragen ohne HTTP stellen können, aber ich glaube, ich verstehe, was Sie zu tun versuchen. Das heißt, GET- und POST-Daten, ohne einen Browser zu verwenden, sondern programmgesteuert. Ist das korrekt?
Rob
4
Ich frage mich, fragen Sie, ob HTTP ohne Methoden definiert worden sein könnte, dh die historischen Gründe für sie; oder ob das Protokoll, wie es derzeit ist, ohne sie verwendet werden könnte, dh ob die Drop-Methoden innerhalb der bestehenden Spezifikation liegen würden?
Ilkkachu
@ilkkachu: Warum muss der Client dem Server mitteilen, wie er etwas ausführen soll? Der Client fordert nur eine URL an und verwendet diese. Der Server kann sie beispielsweise einer Funktion zuordnen, z. B. einem Servlet, und die Antwort zurückgeben. Warum sollte der Kunde jemals angeben müssen, wie etwas ausgeführt werden soll?
user104656
1
@ user104656, Wenn das eine Antwort auf meine Frage ist, bin ich mir immer noch nicht sicher, ob Sie das ursprüngliche Design oder die aktuelle Situation meinen. (Ich habe nicht gesagt, dass es muss oder nicht muss.)
ilkkachu
@Mars und andere: Beispielsweise werden in Google Mail beim Erstellen von Links die PUT / POST-Anforderung und -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?
BioLogic,

Antworten:

33

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.

Caius Jard
quelle
1
Ich habe eine Rückblende von "Wenn das, was Sie schreiben, nicht dem Protokoll entspricht, dann ist es einfach nicht das Protokoll" für jemanden erhalten, der mir sagte, dass er eine "Hausregel" hat, um Schach zu spielen, ohne Rochade zu spielen oder Bauern zu fangen. Ich sagte so etwas wie "Das ist ein interessantes Spiel, aber ohne diese Regeln ist es kein" Schach "." Ändere die Spielregeln und es ist nicht mehr dasselbe Spiel.
Monty Harder
4
Sie haben Kreise darüber geschrieben, wie es ohne die Methoden oder Header nicht das aktuelle HTTP wäre (während die Frage eigentlich nichts über Header aussagt), aber Sie sagen nie, wozu die Methoden dienen und ob ein Protokoll ohne Methoden für dieselben Zwecke funktionieren würde - worum ging es in der Frage?
aaa
1
Warum muss ich sagen, wozu die Methoden gut sind? Dafür gibt es ein Spezifikationsdokument. HTTP ist nichts Magisches, ebenso wenig wie FTP, SMTP oder RTMP - es sind alles nur Bytes, die einen Socket entlang gehen, aber es ist die Reihenfolge, die Darstellung, die Regeln (das Protokoll), denen die Bytes entsprechen, die das Protokoll zu dem machen, was es ist ist. Sie haben etwas in der Frage gelesen, die ich nicht gelesen habe, aber es macht mir auch nichts aus, Ihre Frage zu beantworten: Kann man ein Protokoll ohne Methoden erstellen? - nicht wirklich, aber es kommt darauf an, was Sie mit Methoden meinen. HTTP ist das einzige Protokoll mit HTTP-Methoden, aber alle Protokolle, die ich mir
Caius Jard
..vorgegebene Interaktionsmuster, die ich als Methoden bezeichnen würde; Ohne sie wären sie kein Protokoll, und sie wären nicht in der Lage, eine zuverlässige Kommunikation zwischen Prozessen und Systemen zu erreichen.
Caius Jard
Eigentlich habe ich gesagt, dass es ein Spezifikationsdokument gibt, in dem steht, wozu die Methoden "gut" sind - das muss nicht unbedingt stimmen. die Methoden müssen für nichts "sein"; Wir können einen Webdienst erstellen, der als Antwort auf ein GET Dinge löscht und als Antwort auf ein DELETE neue Benutzer erstellt. Es gibt kein obligatorisches Verhalten für eine Methode, sie existieren nur, weil sie angegeben sind. Systeme bauen auf Protokollen auf, weil sie einen Teil der Arbeit einsparen (wir müssen kein Protokoll sowie ein System erfinden, das es verwendet), aber wenn wir beide Seiten kontrollieren, welche Aspekte des Protokolls werden verwendet ( für) ist ziemlich willkürlich
Caius Jard
12

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.

aaa
quelle
4
"PUT und DELETE waren vor REST moribund" Stimmt nicht. Wie hat WebDAV Ihrer Meinung nach funktioniert?
Patrick Mevzek
3
@PatrickMevzek Ja, aber wurde WebDav von genug Leuten benutzt, um sie für lebendig zu halten, anstatt im Koma zu liegen? ^^
Frank Hopkins,
1
@PatrickMevzek WebDAV ist praktisch ein von HTTP getrenntes Protokoll.
Duskwuff
@duskwuff tools.ietf.org/html/rfc4918 "HTTP-Erweiterungen für Web Distributed Authoring und Versioning (WebDAV)". Nicht so getrennt, es liegt eindeutig darüber.
Patrick Mevzek
1
PATCH wird von REST verwendet, um eine teilweise Änderung (auch als Update bezeichnet) anzuzeigen.
Jmoreno
7

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.

Kris Sinclair
quelle
1
Dies beantwortet die genaue Frage nicht so vollständig (oder vielleicht auch so gut) wie einige andere, aber es ist eine moderne Begründung für die weitere Verwendung der einzelnen Methoden. +1
TCooper
6

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 .

xwindows -on strike-
quelle
3

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

Esben Skov Pedersen
quelle
1
GET with a body entspricht tatsächlich der Spezifikation.
TRiG,
Interessant. Scheint, als ob es im Jahr 2014 geändert wurde.
Esben Skov Pedersen
1
GET mit einem Körper passt sich nicht an, er verletzt ihn nur nicht mehr spezifisch. Es ist jetzt undefiniert, weshalb einige Clients es nicht unterstützen. Ich glaube, CURL ist ein Beispiel
Mars
2

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!

Mars
quelle
1

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.

Stephen Ostermiller
quelle
Ich denke, diese Frage ist auf einer größeren Ebene als eine Website. Nicht "Warum muss ich GET und POST implementieren", sondern "Warum implementieren Browser GET und POST"?
Mars
@Mars Wenn dies der Fall ist, ist die Frage für diese Site nicht thematisch.
Stephen Ostermiller
Ich nehme an, es handelt sich um eine Verlaufsfrage, die anscheinend unter Probleme fällt , die sich auf ganze Websites auswirken (auf der Seite "Frage stellen"). Aber OP ist verschwunden, und ich denke, es wird immer ein Rätsel bleiben
Mars,
0

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

user104723
quelle
1
"GET, POST, PUT usw. sind nur historische Konventionen" - Sie sind keine Konventionen. Sie haben Verhaltensweisen genau spezifiziert und darüber hinaus haben sie unterschiedliche Verhaltensweisen genau spezifiziert .
Jörg W Mittag
Als Web-API-Entwickler kann ich GETs leicht mit POSTs austauschen und umgekehrt. Dies ist die Grundlage für meine Antwort. Um ehrlich zu sein, hat POST weniger Probleme zu bewältigen
user104723
-1

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.

nick012000
quelle
Abgesehen davon, dass unter HTTPS der Inhalt des GET im Netzwerk überhaupt nicht im Klartext vorliegt ... Und Angreifer können durch reines Glück, rohe Gewalt oder andere Techniken bösartigen Code einschleusen, ohne dass sie sehen müssen, dass bereits etwas passiert.
Patrick Mevzek