RFC 10008: Die neue HTTP-Methode, die headless Storefronts neu denken lässt

Die IETF hat im Juni 2026 einen neuen HTTP-Standard verabschiedet, über den im Commerce-Frontend bisher kaum jemand redet. RFC 10008 definiert eine neue HTTP-Methode: QUERY. Das klingt unspektakulär. Ich glaube, es ist keines.

Das Problem, das QUERY löst

Jedes headless Frontend lebt von Abfragen. Suche, Faceted Filtering, Produktlisten, GraphQL-Queries, Personalisierung - all das sind im Kern strukturierte Anfragen an einen Daten-Endpoint. Bisher hatten wir dafür exakt zwei Optionen, und beide sind unbefriedigend.

GET ist das Richtige semantisch: cachebar, safe (löst keinen State-Change aus), idempotent (gefahrlos wiederholbar). Aber: die Query muss in die URL. RFC 9110 empfiehlt eine URL-Länge von unter 8.000 Oktett - bei komplexen Filterstrukturen, verschachtelten GraphQL-Queries oder personalisierten Suchanfragen ist das schnell zu wenig. Außerdem landen Query-Parameter in Logs, Proxy-Protokollen und Browser-Historien. Für sensible Filterparameter keine gute Eigenschaft.

POST löst das URL-Problem: der Payload geht in den Body, beliebig groß, kein URL-Limit. Aber POST ist semantisch nicht safe und nicht idempotent - der HTTP-Layer kann nicht wissen, ob ein wiederholter POST harmlos ist oder einen State-Change auslöst. Die Konsequenz: CDNs und Edge-Proxies cachen POST nicht. Genau deshalb schlägt heute fast jede GraphQL-Query am CDN vorbei direkt auf den Origin durch. Persisted Queries, Query-Hashing, CDN-Bypässe - das sind alles Workarounds für dieses fundamentale Mismatch. Warum sich solche Workarounds über die Zeit zu echten Kosten summieren, habe ich im Composable-Reality-Check ausgeführt.

Was QUERY anders macht

RFC 10008 schließt diese Lücke mit einer neuen HTTP-Methode, die beide Eigenschaften vereint. Die formale Definition (Abstract, §2, Tabelle 1 des RFC):

• Payload im Body - wie POST, kein URL-Limit, kein URL-Leakage
• Explizit safe - QUERY hat keinen Seiteneffekt, der Server darf das als Garantie annehmen
• Explizit idempotent - ein HTTP-Client, ein Proxy oder ein CDN darf QUERY-Requests gefahrlos wiederholen

Das ist keine semantische Feinheit. Es ist die Grundlage, auf der CDNs und Edge-Caches Caching-Entscheidungen treffen. Mit QUERY können komplexe Suchanfragen und Filterqueries wieder am Edge gecacht werden - der Cache-Key schließt den Request-Body und Request-Metadaten ein (§2.7). Origin-Last sinkt, Latenz sinkt, Storefronts werden schneller ohne Änderung am Business-Logic-Layer.

Zusätzlich führt RFC 10008 das Header-Feld Accept-Query ein (§3). Es macht maschinell auffindbar, welche Query-Formate ein Endpoint unterstützt - eine saubere Grundlage für Format-Discovery statt hardcodierter Client-Annahmen.

Ein wichtiger Hinweis zur CORS-Seite: weil QUERY nicht in der CORS-safelist-Methoden-Liste des WHATWG Fetch-Standards steht, löst es einen Preflight-Request aus (§4 Security Considerations). Das ist kein Bug, sondern die erwartete Konsequenz einer neuen Methode. Browser-seitig muss das berücksichtigt werden.

Ehrlich über den Adoptionsweg

GraphQL-over-QUERY ist nicht Teil des RFC und noch nicht standardisiert. RFC 10008 definiert die Methode, nicht die Payload-Formate. Ob und wie GraphQL-Clients QUERY adopten, wird eine separate Diskussion. Ich erwähne es hier, weil das mittelfristig Persisted-Query-Workarounds überflüssig machen könnte - als Möglichkeit, nicht als Versprechen.

Und selbst wenn Clients bereit sind: Server, CDNs, Reverse Proxies und Browser müssen QUERY erst unterstützen, bevor der Standard in Produktion sinnvoll nutzbar ist. Das ist ein Mehrjahres-Weg. Wer jetzt darüber schreibt, tut es nicht, weil QUERY morgen production-ready ist. Wir tun es, weil der Zeitpunkt, an dem Standards gebaut sind, nicht der richtige ist, um anfangen zu denken.

Warum das eine strategische Frage ist - nicht nur eine technische

Hier wird es interessant, und hier ist der Punkt, an dem mir die Architektur-Entscheidung, die wir bei Laioutr getroffen haben, wichtig erscheint.

Wer ein headless Frontend als Individual-Software gebaut hat - ein eigenes Next.js-Projekt, eine Nuxt-App, einen eigenen API-Layer - muss QUERY in jeder Storefront einzeln nachziehen. Transport-Layer anfassen. Caching-Logik neu denken. CORS und Preflight-Handling. Retry-Strategien. Cache-Keys konfigurieren. Alles testen. Pro Projekt. Wieder und wieder, für jeden Kunden, für jede Storefront.

Das ist nicht ein technisches Problem, das einmal gelöst wird. Es ist ein Multiplikationsproblem: so viele Projekte wie Storefronts.

Wer auf einer Plattform baut, hat eine andere Ausgangslage. Bei Laioutr abstrahieren wir die Daten- und Transport-Schicht. Unsere Kunden komponieren Sections und Blocks - sie verdrahten keine HTTP-Calls von Hand. Die Plattform besitzt die Schicht, in der QUERY relevant wird.

Was das bedeutet: Sobald das Ökosystem so weit ist - Servers, CDNs, Browser, GraphQL-Clients - , können wir den Standard zentral einziehen. Jede Storefront auf Laioutr profitiert davon, ohne dass ein einziger Kunde seinen Code anfasst. Keine 50 parallelen Migrations-Tickets. Keine Divergenz zwischen älteren und neueren Projekten. Es ist dieselbe Logik, mit der wir einen Vendor-Wechsel ohne komplettes Replatforming möglich machen - die Plattform absorbiert den Change, nicht der Kunde.

Wir bereiten die Plattform heute schon darauf vor. Nicht weil QUERY morgen live geht, sondern weil Architektur-Entscheidungen, die später elastisch sein sollen, früh getroffen werden müssen.

Was das für dich bedeutet - heute

Wenn du headless baust und auf Individual-Software setzt, ist RFC 10008 heute kein operativer Handlungsbedarf. Aber es ist ein guter Moment, zwei Fragen zu stellen:

Erste Frage: Wer in deiner Architektur besitzt den Transport-Layer? Wenn die Antwort "wir selbst - pro Projekt" ist, dann ist das ein Hinweis auf die Art von Aufwänden, die Protocol-Shifts wie dieser mit sich bringen werden. Frontend-Unabhängigkeit wird genau aus solchen Gründen zum Buying-Criterion - mehr dazu in unserem Wochen-Wrap.

Zweite Frage: Welche deiner heutigen Workarounds - Persisted Queries, Query-Hashing, CDN-Bypässe - lösen eigentlich ein Problem, das sich mit einem saubereren HTTP-Fundament von selbst erledigt?

Eine Frontend-Management-Plattform ist nicht dafür da, dir diese Fragen wegzunehmen. Sie ist dafür da, dass du deine Antworten auf sie nicht in Transport-Layer-Code gießen musst.

RFC 10008 ist veröffentlicht: https://www.rfc-editor.org/rfc/rfc10008.html. Autoren: J. Reschke (greenbytes), J. M. Snell (Cloudflare), M. Bishop (Akamai). Standards Track, Juni 2026.

Wenn ihr headless baut und wissen wollt, was QUERY konkret für eure Architektur bedeutet - schreibt mir oder bucht eine Demo.

Auf einem frontend-unabhängigen Fundament bauen

Composable Headless Frontend · Performance & Core Web Vitals · Agentic Frontend Management Platform