javascript - Sind Get und Post nur Konventionen?

Nehmen wir zum Beispiel an, get sei idempotent und sicher? Bedeutet das, dass dies nur eine Regel ist? Wir können Get auch als Post-Through-Code verwenden (nicht idempotent und nicht sicher)

Antwortinhalt:

Nehmen wir zum Beispiel an, get sei idempotent und sicher? Bedeutet das, dass dies nur eine Regel ist? Wir können Get auch als Post-Through-Code verwenden (nicht idempotent und nicht sicher)

Es gibt ziemlich viele Antworten und es gibt unterschiedliche Meinungen, deshalb habe ich mich der Genauigkeit halber entschieden, etwas zu recherchieren

Die erste Schlussfolgerung ist, dass es sich in Bezug auf die Sicherheit und Idempotenz von GET und POST nicht nur um eine Konvention, sondern um einen Standard handelt, aber im Standard gibt es keine Einschränkungen hinsichtlich Sicherheit und Idempotenz

Um dieses Problem zu lösen, habe ich das RFC 7231-Dokument herausgesucht. Das vorherige RFC 2616 wurde durch die sechs Protokollbeschreibungen RFC7230 – RFC7235 ersetzt. Die Methodendefinition befindet sich in RFC 7231

https://tools.ietf.org/html/r...

Was die Sicherheitsmethoden und idempotenten Methoden betrifft, um die es in diesem Thema geht

Kapitel 4.2.1 und 4.2.2 von RFC 7231 definieren klar, was „Safe Methods“ (sichere Methoden) und „Idempotent Methods“ (idempotente Methoden) sind

Dann lautet die Definition der Sicherheitsmethode im in RFC definierten Standard (mit meiner eigenen losen Übersetzung)

Anforderungsmethoden gelten als „sicher“, wenn ihre definierte Semantik im Wesentlichen schreibgeschützt ist, d. h. der Client fordert keine Statusänderung auf dem Ursprungsserver als Ergebnis der Anwendung einer sicheren Methode an Zielressource. Ebenso ist nicht zu erwarten, dass die angemessene Verwendung einer sicheren Methode zu Schäden, Eigentumsverlusten oder ungewöhnlicher Belastung für den Ursprungsserver führt

Anforderungsmethoden gelten als „sicher“, wenn sie schreibgeschützter Natur sind oder wenn der Client eine Methode auf eine Ursprungsserverressource anwendet und keine Änderungen im Ergebnis der Anforderung erwartet, wenn sich der Status ändert. Und die Verwendung angemessener Sicherheitsmethoden verursacht keinen Schaden, keinen Verlust von Attributen oder eine ungewöhnliche Belastung des Servers

Diese Definition sicherer Methoden verhindert nicht, dass eine Implementierung Verhalten einschließt, das potenziell schädlich ist, das nicht vollständig schreibgeschützt ist oder beim Aufrufen einer sicheren Methode Nebenwirkungen verursacht. Wichtig ist jedoch, dass der Client hat dieses zusätzliche Verhalten nicht angefordert und kann dafür nicht zur Verantwortung gezogen werden. Beispielsweise hängen die meisten Server nach Abschluss jeder Antwort Anforderungsinformationen an, um auf Protokolldateien zuzugreifen, unabhängig von der Methode, und dies gilt als sicher, auch wenn die Protokollspeicherung möglicherweise beeinträchtigt wird Der Server ist voll und stürzt ab. Ebenso hat eine sichere Anfrage, die durch die Auswahl einer Werbung im Web initiiert wird, häufig den Nebeneffekt, dass ein Werbekonto belastet wird.

Die Definition dieser sicheren Methode verhindert nicht die Implementierung von Verhaltensweisen, die das Ergebnis beeinträchtigen, nicht vollständig schreibgeschützt sind oder andere Nebenwirkungen hervorrufen. Wichtig ist jedoch, dass (wenn diese Änderungen auftreten) der Kunde Ebene Es wird gesagt, dass keine Anfrage vorliegt (das heißt, es wird zum Zeitpunkt der Anfrage nicht erwartet), sodass der Client nicht dafür verantwortlich ist. Beispielsweise zeichnen die meisten Server die Anfrageinformationen nach jeder Anfrage im Zugriffsprotokoll auf. Aber unabhängig von der Art der Anfrage kann selbst das (scheinbar) sichere Verhalten der Protokollierung zum Absturz des Servers führen. Ebenso hat eine sichere Anfrage für eine Werbung im Web häufig Nebenwirkungen auf das Werbekonto 🎜>

Von den in dieser Spezifikation definierten Anforderungsmethoden sind die Methoden GET, HEAD, OPTIONS und TRACE als sicher definiert

Gemäß der Definition dieser Anforderungsmethode sind die Methoden GET, HEAD, OPTIONS und TRACE als sicher definiert

Die Definition der idempotenten Methode lautet (fügen Sie auch meine eigene lose Übersetzung bei)

Eine Anforderungsmethode gilt als „idempotent“, wenn die beabsichtigte Wirkung mehrerer identischer Anforderungen mit dieser Methode auf den Server die gleiche ist wie die Wirkung einer einzelnen solchen Anforderungsmethode Die durch diese Spezifikation definierten PUT-, DELETE- und sicheren Anforderungsmethoden sind idempotent.

Eine Anforderungsmethode gilt in den folgenden Situationen als idempotent: Wenn eine Anforderung in mehreren Anforderungen denselben Effekt wie in einer einzelnen Anforderung erzeugt, umfassen die definierten Anforderungsmethoden PUT, DELETE und andere „sichere“ Methoden. „Methode“ ist ebenfalls idempotent

Mein Fazit ist also, dass es sich in Bezug auf die Sicherheit und Idempotenz von GET und POST nicht nur um eine Konvention, sondern um einen Standard handelt, aber im Standard gibt es keine Einschränkungen hinsichtlich Sicherheit und Idempotenz

(Es scheint, als ob es bedeutet, es noch nicht zu sagen)

== Hier ist die voreilige Originalantwort ==

Es wurde noch nicht einmal das Niveau der Einigung erreicht, man sollte sagen, dass dies eine bewährte Vorgehensweise ist

Es gibt viele Websites, die dies nicht tun

Aber das hindert uns nicht daran, diese Best Practice selbst umzusetzen

GET POST ist ein Standard, nicht nur eine Konvention.
Der Unterschied zwischen einer Konvention und einem Standard besteht darin, ob sie durchgesetzt wird.
Die Ausführung der Vereinbarung hängt vom Einzelnen ab und GET POST wird standardmäßig vom Browser zuverlässig ausgeführt.
Abschließend werden wir feststellen, dass es zumindest in einer Browserumgebung einige Unterschiede zwischen GET und POST gibt.
Zum Beispiel: GET kann keine Formulardaten übertragen, daher kann GET im Code nicht vollständig als Ersatz für POST verwendet werden.

Dies ist eine allgemeine Regel, die jedoch nicht festgeschrieben ist, um andere Verwendungen zu verhindern. Sie kann je nach persönlicher Meinung flexibel verwendet werden.

Ja, meiner Meinung nach ist das derzeit besonders beliebte RESTful tatsächlich die eigentliche Implementierung des http-Protokolls

Wenn Sie nicht so schreiben, werden Ihre Kollegen Sie auslachen. . .

Aus Sicht von CURD schreibt niemand vor, dass GET eine Abfrage und POST eine Hinzufügung, Löschung und Änderung sein muss. Es gibt keine solche Bedeutung.

Ja, es ist eine Konvention.

Methoden des HTTP-Protokolls der Anwendungsschicht, z. B. Essen mit Stäbchen, Löffeln und Gabeln.

So kommt die Vereinbarung zustande, und die Bedeutung der Vereinbarung ist eine Vereinbarung.
Wenn Sie den Client und den Server selbst implementieren, können Sie diese Vereinbarungen natürlich ignorieren. Wenn Sie jedoch ein Andocken durchführen und die andere Partei sich an die Vereinbarung hält, dürfen Sie nicht passieren, wenn Sie sich nicht daran halten Vereinbarung.

Dies ist ein Befürworter und Standard. Missbrauch ist strengstens untersagt. Sowohl mobile Apps als auch Websites sind datengesteuerte Anwendungen der oberen Ebene, und die Kommunikation basiert stark auf dem http-Protokoll. Daher würde ich vorschlagen, dass jeder den Unterschied zwischen Get und Post so gut wie möglich versteht. Es handelt sich nicht nur um eine Konvention, sondern um einen Standard Regel. Bei Änderungs-, Lösch- und Erstellungsvorgängen kann get nicht verwendet werden. Es gibt weitere Unterschiede. Dies ist die wichtigste Voraussetzung. Genauer gesagt ist dies die Verwirklichung beruflicher Fähigkeiten.

Wenn Ihr Front-End und Back-End beispielsweise Cookies verwenden, um den Status zu speichern, und Sie get verwenden, um Daten hinzuzufügen oder zu ändern, ruiniert CSRF Ihre Website = =