Zwanzig Storefront-Funktionen gegen die Store API
Dreimal falsch gemessen, bevor die Methode taugte: Routennamen, Importe, Konstruktoren. Erst der zwanzigfache echte Aufruf gab eine Antwort — und sie ist kürzer als erwartet.
Ergebnis
20 von 20 erreichbar
Alle zwanzig geprüften Handelsfunktionen antworten über die Store API. Was fehlt, ist keine Handelsfunktion, sondern die Maschinerie einer HTML-Storefront. Davon ist für ein Headless-Frontend genau eines relevant: das Captcha, für das es null Store-API-Routen gibt.
Diese Frage hat uns dreimal eine falsche Antwort geliefert, bevor die Methode taugte. Das gehört an den Anfang, weil die falschen Antworten alle plausibel aussahen.
Drei Methoden, die nicht funktioniert haben
Erstens: Routennamen vergleichen. Man nimmt die Liste der Storefront-Routen,
die Liste der Store-API-Routen, sucht nach Entsprechungen. Ergebnis: eine Zahl,
die nach Erkenntnis aussieht und keine ist. frontend.detail.page und
/store-api/product/{id} heißen verschieden und tun dasselbe.
Zweitens: Quelltext nach Importen durchsuchen. Man prüft, ob ein
Storefront-Controller eine Store-API-Routenklasse importiert. Ergebnis: 24
angebliche Lücken — darunter sieben Routen aus dem Theme-Bereich, die gar keine
Storefront-Funktionen sind, und frontend.navigation.page, für das
/store-api/category/{navigationId} nachweislich existiert. Ursache: Controller
importieren Interfaces, keine Implementierungen.
Drittens: Konstruktorparameter rekursiv verfolgen. Technisch sauberer, und
das Ergebnis war versionsabhängig instabil — 6 Lücken in 6.6, 15 in 6.7, mit
frontend.detail.page als angeblicher Lücke, obwohl /store-api/product/{id}
existiert.
Drei Methoden, drei Zahlen, jede falsch. Der Fehler war derselbe: Sie haben die Verdrahtung gemessen, nicht die Fähigkeit.
Die Methode, die trägt
Zwanzig Funktionen vorab benennen. Jede einzeln aufrufen. Aufschreiben, was zurückkommt.
Das ist unspektakulär und hat einen Vorteil, den keine Code-Analyse hat: Es misst, was ein Frontend-Entwickler tatsächlich tun würde.
Das Ergebnis
| Funktion | Endpunkt | HTTP |
|---|---|---|
| CMS-Seite / Kategorie | POST /store-api/category/{id} | 200 |
| Kategorie-Listing | POST /store-api/product-listing/{id} | 200 |
| Produktdetail | POST /store-api/product/{id} | 200 |
| Produktsuche | POST /store-api/search | 200 |
| Suchvorschlag | POST /store-api/search-suggest | 200 |
| Navigation | POST /store-api/navigation/{a}/{r} | 200 |
| Warenkorb lesen | GET /store-api/checkout/cart | 200 |
| Warenkorb füllen | POST /store-api/checkout/cart/line-item | 200 |
| Versandarten | POST /store-api/shipping-method | 200 |
| Zahlarten | POST /store-api/payment-method | 200 |
| Länder | POST /store-api/country | 200 |
| Anreden | POST /store-api/salutation | 200 |
| Sprachen | POST /store-api/language | 200 |
| Währungen | POST /store-api/currency | 200 |
| Kontext lesen | GET /store-api/context | 200 |
| Registrierung | POST /store-api/account/register | 400 |
| Anmeldung | POST /store-api/account/login | 401 |
| Newsletter | POST /store-api/newsletter/subscribe | 400 |
| Kontaktformular | POST /store-api/contact-form | 400 |
| Sitemap | GET /store-api/sitemap | 200 |
20 von 20. Die vier Antworten mit 400 und 401 sind Validierungsfehler auf absichtlich leere Rümpfe — der Endpunkt existiert und prüft. Ein fehlender Endpunkt hätte 404 geliefert.
Und jetzt die Gegenrichtung
Eine Stichprobe, die überall 200 liefert, beweist nicht, dass nichts fehlt. Also
die umgekehrte Suche: Welche frontend.*-Routen haben keine Entsprechung?
| Bereich | frontend-Routen | Store-API |
|---|---|---|
| Captcha | basic-captcha.load, basic-captcha.validate | 0 Routen |
| Cookie | cookie.offcanvas, .permission, .consent.offcanvas, .groups | /store-api/cookie-groups |
| App-Skripte | script_endpoint | /store-api/script/{hook} |
| Wartung | maintenance.page, .singlepage | 0 — irrelevant |
| robots.txt | robots.txt | 0 — irrelevant |
| Passwortwechsel | well-known.change-password | 0 — irrelevant |
Die letzten drei sind HTML-Maschinerie. Ein Headless-Frontend hat seine
eigene Wartungsseite, seine eigene robots.txt und seinen eigenen
.well-known-Pfad. Dass die Store API sie nicht liefert, ist kein Mangel.
Cookie-Gruppen gibt es — nur das Rendern der Auswahlbox nicht, und das ist Aufgabe des Frontends. App-Skripte gibt es ebenfalls.
Bleibt genau eines: das Captcha.
Die eine echte Lücke
Shopware bringt eine einfache Captcha-Prüfung für Formulare mit — Registrierung, Kontaktformular, Newsletter. Sie hat zwei Storefront-Routen und keine Entsprechung in der Store API.
Für ein Headless-Frontend heißt das: Der Bot-Schutz der Formularstrecken ist nicht mitgeliefert, sondern selbst zu bauen — mit einem eigenen Dienst, einer eigenen Prüfung und einer eigenen Entscheidung darüber, was bei Verdacht passiert.
Das ist keine große Lücke. Aber es ist die einzige, die tatsächlich Arbeit bedeutet, und sie steht in keiner Vergleichstabelle.
Was noch zählt, aber keine Lücke ist
Die Store API begrenzt eine Anfrage auf 100 Datensätze. Ein Aufruf mit
limit: 101 wird mit FRAMEWORK__QUERY_LIMIT_EXCEEDED abgelehnt. Die Admin-API
erlaubt an derselben Stelle 500.
Das ist keine fehlende Fähigkeit, aber eine Architekturentscheidung mit Folgen: Ein Katalogabzug über 10.000 Produkte braucht über die Store API 100 Anfragen, über die Admin-API 20. Wer nachts synchronisiert, nimmt die Admin-API — und zwar nicht wegen der Funktionen, sondern wegen der Seitenzahl.
Was das für die Entscheidung bedeutet
| Frage | Antwort |
|---|---|
| Kann ein Headless-Frontend alles, was die Storefront kann? | Für die zwanzig geprüften Handelsfunktionen: ja |
| Was muss selbst gebaut werden? | Bot-Schutz der Formulare. Dazu alles, was HTML ist — was ohnehin der Zweck eines eigenen Frontends ist |
| Wo ist der eigentliche Aufwand? | Nicht in fehlenden Endpunkten, sondern im Frontend selbst: Zustand, Routing, Rendering, SEO |
| Wann trotzdem Admin-API? | Für Massenabzüge. 500 statt 100 je Anfrage |
Die verbreitete Sorge, die Store API könne zu wenig, hat sich in dieser Messung nicht bestätigt. Die Arbeit liegt woanders — nur nicht dort, wo die Vergleichstabellen hinzeigen.
Grenzen dieser Messung
Zwanzig Funktionen sind eine Stichprobe, keine Vollerhebung. Geprüft ist, dass ein Endpunkt antwortet, nicht, dass er feldgleich dasselbe liefert wie die Storefront-Seite — ein Feldvergleich je Endpunkt wäre eine eigene Untersuchung.
Nicht geprüft wurde der Bestellabschluss. Warenkorb lesen und füllen sind in der Stichprobe, der Weg von dort bis zur bestätigten Bestellung ist es nicht.
Und die Installation trug neun Plugins. Eine Erweiterung kann eigene Store-API-Routen mitbringen — die Zahl 97 ist die dieser Installation, nicht die des blanken Kerns.