HTTP GET und POST Semantik und Einschränkungen

Question

Anfang dieser Woche musste ich etwas tun, das sich wie eine Semantikverletzung anfühlt. Lassen Sie mich erklären.

Ich machte eine einfache AJAX-Client-Anwendung, die eine Anfrage an einen Dienst mit einer bestimmten Anzahl von Parametern stellen sollte. Da die gesamte App grundsätzlich schreibgeschützt ist, dachte ich, dass die Verwendung von HTTP GET der richtige Weg ist. Einige der Parameter, die ich übergeben musste, waren einfach (z. B. die Sortierreihenfolge oder die Seitennummer).

Allerdings könnte einer der erforderlichen Parameter von variabler Länge sein, und das machte mir Sorgen. Da ich alle Parameter in der Querystring der GET-Anfrage codiert hatte, schien es mir, dass dies eine unnötige upper limit of (roughly) 2000 characters for the request URL platziert. Und natürlich habe ich keine 500 Zeichen langen Anfrage-URLs gesehen.

Also, da eine POST-Anfrage keine Einschränkung hat, entschied ich mich zu wechseln. Aber das fühlt sich nicht richtig an. Ich habe den Eindruck, dass ein POST eine Änderung der Daten bedeutet - aber ich benutze es für eine einfache schreibgeschützte Anfrage.

Gibt es einen besseren Weg, dies zu tun? Um ein GET mit vielen Parametern durchzuführen? Ich habe von einer Methode gehört - wo Sie eine vorläufige POST der Parameter selbst durchführen, und dann ein GET durchführen. Aber diese Technik lässt viel zu wünschen übrig.

Aber nach diesem spezifischen Fall, Was sind die wahren Semantiken und Einschränkungen von HTTP-Anfrage-Methoden? Und warum unterstützt GET keine Art von Parameter-Payload? Die Verwendung der Querystring in der URL fühlt sich fast wie ein Hack für mich an.

Answer 1

Ein paar Punkte zu diesem Thema:

• Die HTTP-Spezifikation (RFC 2616) keine Anforderungen Parameter haben forbit GET, so ist es nicht eine Frage der Semantik von HTTP GET selbst. Viele HTTP-Stacks (für Clients, Dienste oder Proxies) verbieten jedoch Körper in HTTP-Anfragen, die Tatsache, dass sie nicht verwendet werden können, ist meistens ein Implementierungsdetail (ziemlich weit verbreitet) als ein semantisches Problem mit den HTTP GET-Anfragen
• In ähnlicher Weise wird die Beschränkung der Länge der URI (oder Abfragezeichenfolge) auch im RFC nicht angegeben. Es handelt sich hauptsächlich um eine Sicherheitsminderung, die von mehreren HTTP-Serverstapeln implementiert wird, um zu verhindern, dass ein fehlerhafter Client Serverressourcen verbraucht (in IIS/ASP.NET ist das Standardlimit beispielsweise 2 KB, aber Sie können es über einige Elemente in web.config erhöhen). Auch hier handelt es sich nicht um eine semantische, sondern um eine praktische Frage.
• POST-Anfragen zeigen Datenänderungen an, wenn Sie die REST-Philosophie befolgen. Es gibt jedoch viele Beispiele für HTTP POST-Anfragen, die für schreibgeschützte Operationen verwendet werden. SOAP verwendet POST in allen seinen Anforderungen, unabhängig davon, ob die Operation, die es aufruft, eine "sichere" oder eine "modifizierende" Operation ist. Sie können also auch POST für diese Operationen verwenden. Wenn Sie jedoch von der REST-Verwendung (und der "kanonischen" HTTP-Verwendung) abweichen, gehen einige der Funktionen des Protokolls verloren, z. B. das Zwischenspeichern, das für GET-Anforderungen, nicht jedoch für POST angewendet werden kann.
• Ihr Beispiel der Verwendung von zwei Anfragen (POST mit Parametern + GET, um die Ergebnisse "zu bekommen") scheint übertrieben. Wie ich bereits erwähnt habe, bedeuten POST-Anfragen nicht unbedingt, Ressourcen zu modifizieren. Sie müssen also kein neues "Protokoll" (POST + GET) erstellen, um auf Ihre Operation zugreifen zu können, wenn eine Anfrage genügt.