Die HTTP GET-Methode wird in der Regel zum Abrufen von Daten verwendet, und viele Entwickler gehen davon aus, dass sie keinen Text unterstützt. Aber die Wahrheit ist, dass GET-Anfragen einen Text enthalten können. Gemäß dem Standard (RFC 7231 §4.3.1) können GET-Anfragen einen Text haben, der jedoch „keine definierte Semantik“ hat. Hier der Auszug zum Post mit einem Body:
Ist es eine gute Idee, GET mit einem Body zu verwenden? → das hängt von Ihrem Anwendungsfall ab.
Wann GET mit einem Body funktioniert
GET /items
{ "ids": [1, 2, 3, ..., 1000] }1. Direkte Kommunikation zwischen Client und Server
Wenn Ihre API für die direkte Kommunikation zwischen Client und Server konzipiert ist und keine Vermittler (z. B. Proxys oder Caches) vorhanden sind, kann die Verwendung von GET mit einem Text gut funktionieren.
- Der Server kann den Text korrekt verarbeiten.
- Keine Zwischenhändler bedeuten kein Risiko, dass der Körper fallen gelassen oder falsch interpretiert wird.
2. Spezifische Anwendungsfälle in APIs
Einige Systeme verwenden GET bereits mit einem Text für erweiterte Abfragen, z. B.:
- Elasticsearch unterstützt GET mit einem Body für strukturierte Suchen.
- GraphQL-APIs erlauben manchmal Abfragen in GET-Texten für ein besseres Caching.
3. Beibehaltung der REST-Semantik
Wenn Ihr Anwendungsfall ausschließlich das Abrufen von Daten umfasst (keine Nebenwirkungen), können Sie durch die Verwendung von GET mit einem Body die REST-Prinzipien einhalten, da GET für den Datenabruf konzipiert ist.
Warum GET mit einem Body riskant sein kann
Während GET mit einem Body in kontrollierten Umgebungen funktioniert, gibt es Risiken:
1. Probleme
mit Vermittlern Wenn Ihre API jemals mit Proxys, Caches oder anderen Vermittlern interagiert, können diese:
- den Body komplett entfernen.
- den Body ignorieren, was zu falschen Antworten führt.
- Die Anforderung wird falsch interpretiert, was zu Fehlern führt.
2. Caching-Herausforderungen
HTTP-Caches verwenden die URL und die Methode, um zu bestimmen, was zwischengespeichert werden soll. Wenn der Text wichtige Parameter enthält, werden diese von Caches nicht berücksichtigt, was zu inkonsistentem Verhalten führt.
3. Eingeschränkte Adoption
Nicht alle Tools, Bibliotheken oder Frameworks unterstützen GET mit einem Text. Einige mögen es rundweg ablehnen.
4. Sicherheitsrisiken
Wenn der Text vertrauliche Daten enthält, können Vermittler diese protokollieren oder unbeabsichtigt offenlegen.
Wann sollte man GET mit einem Body vermeiden?
1. Öffentliche APIs
Wenn Ihre API für Clients von Drittanbietern oder das offene Web verfügbar ist, vermeiden Sie GET mit einem Text. Sie können die Vermittler zwischen dem Client und dem Server nicht kontrollieren.
2. Komplexe Systeme
In verteilten Systemen, an denen Proxys, Gateways oder CDNs beteiligt sein können, ist GET mit einem Text unzuverlässig.
Alternativen zu GET with a Body
Wenn GET mit einem Body nicht möglich ist, können Sie Folgendes tun:
1. Verwenden von Abfrageparametern mit GET
Halten Sie sich für kleinere Datennutzlasten an Abfragezeichenfolgen:
GET /products?ids=1,2,3,...,1000- Cache-freundlich.
- Zuverlässig über alle Systeme hinweg.
Wenn die Nutzlast zu groß ist, teilen Sie die Anforderung nach Client in kleinere Blöcke auf:
GET /products?ids=1,2,3,...,100
GET /products?ids=101,102,103,...,2002. Request Body mit POST
Die Verwendung von POST mit einemRequest für den Datenabruf kann gegen REST-Prinzipien verstoßen und unnötige Verwirrung stiften. REST basiert auf der Idee, dass GET für den Abruf und POST für das Erstellen oder Verarbeiten von Daten gedacht ist.
Fazit
- Verwenden Sie GET mit einem Body sparsam: Nur in Umgebungen, in denen Sie den Client und den Server kontrollieren und keine Vermittler vorhanden sind.
- Vermeiden Sie für öffentliche APIs GET mit einem Text: Halten Sie sich aus Gründen der Kompatibilität und Zuverlässigkeit an Abfrageparameter oder POST.
- Klar dokumentieren: Wenn Sie sich entscheiden, GET mit einem Text zu verwenden, dokumentieren Sie Ihr API-Verhalten, um Verwirrung unter den Benutzern zu vermeiden.
GET ist die richtige Wahl für den Abruf von Daten, selbst wenn große oder komplexe Anfragen bearbeitet werden.
GET mit einem Body kann funktionieren, aber nur in kontrollierten Setups ohne Vermittler.
POST für den Datenabruf sollte vermieden werden, da es das API-Design erschwert und gegen REST-Prinzipien verstößt
Ein anderer Beitrag zum Lesen: Warum sorted() in Python anders funktioniert, als Sie erwarten