Wie groß Shopwares API wirklich ist

„Shopware hat eine riesige API." Der Satz stimmt und führt in die Irre, weil er zwei sehr verschiedene Dinge zusammenwirft. Wir haben beide gezählt.

Das Ergebnis

Alle Zahlen sind Kernzahlen — die Routen der installierten Erweiterungen sind getrennt ausgewiesen, weil die beiden Testsysteme unterschiedliche Plugins tragen (fünf gegen neun).

Warum die Trennung nötig war. Die Rohzahlen lauten 2.070/2.277 für die Admin-API und 91/97 für die Store-API. In beiden stecken die Endpunkte unserer eigenen Erweiterungen — allein die Merkliste bringt zehn Store-API-Endpunkte mit. Ein erster Anlauf trennte nach dem Routennamen und lag daneben: frontend.wishlist.* gehört zum Kern, frontend.pixup.wishlist.* zu unserem Plugin. Massgeblich ist der Namensraum des Controllers.

Warum 2.248 die falsche Zahl ist

Shopwares Datenschicht erzeugt zu jeder API-fähigen Entität automatisch denselben Satz Routen: auflisten, einzeln lesen, anlegen, ändern, löschen, suchen, IDs suchen, aggregieren. Acht Operationen, rund 250 Entitäten — das sind die 2.000. Darin stecken auch die CRUD-Routen der Entitäten, die Erweiterungen mitbringen — sie werden vom Kern erzeugt und lassen sich nicht sinnvoll abziehen.

Diese Routen sind nützlich, aber sie sind Arithmetik. Sie sagen nichts darüber, was Shopware kann; sie sagen, wie viele Tabellen es hat. Eine Integration, die sich davon beeindrucken lässt, plant an der falschen Zahl.

Die eigentlich geschriebene Oberfläche sind die 179 _action-Endpunkte. Dort steht, was Shopware tut statt speichert: Dokumente erzeugen, Bestellungen in einen Zustand überführen, Caches leeren, Indizes anstoßen, Mails versenden, Importe starten.

Zwischen 6.6 und 6.7 sind 33 davon dazugekommen (146 auf 179) — das ist der Zuwachs an tatsächlicher Funktion.

Die Zahl, auf die es ankommt

87.

So viele Endpunkte hat die Store-API des Kerns in 6.7, also die API, die ein Kunde oder ein Frontend benutzt. Sie ist bewusst schmal: Katalog lesen, Warenkorb führen, Bestellung abschließen, Konto verwalten.

Für jede Headless-Überlegung ist das die relevante Größe. Nicht „Shopware hat 2.500 Routen", sondern „mein Frontend darf 87 davon benutzen, und die Frage ist, ob sie reichen".

Ob sie reichen, haben wir hier nicht gemessen. Das ist ein Fähigkeitsvergleich — welcher Storefront-Vorgang hat welche Entsprechung — und eine Zählung beantwortet ihn nicht. Ein erster Anlauf über Routennamen lieferte bei uns eine Scheinzahl, die wir verworfen haben.

Die sechs Storefront-Routen

101 auf 107. Sechs mehr, und sie sind derselbe Befund wie in einem früheren Research: Eine dieser Routen hat bei uns eine Plugin-Route verdrängt, ohne dass sich irgendetwas als Fehler gemeldet hätte — wenn der Shopware-Kern eine Plugin-Route verdrängt.

Für eine Update-Prüfung heißt das: debug:router vor und nach dem Update laufen lassen und die Ausgaben gegeneinanderhalten. Eine Minute Aufwand für eine Regression, die sich sonst nicht meldet.

Was Sie mit den Zahlen anfangen

Was die Zählung nicht hergibt

Keine Aussage über Mächtigkeit. Ein _action-Endpunkt kann eine Zeile Code sein, eine generierte CRUD-Route kann mit Filtern und Aggregationen sehr weit tragen. Die Klassifikation trennt Herkunft, nicht Wert.

Keine Aussage über Ihren Shop. Die Zahlen gelten für den Kern plus die Erweiterungen der gemessenen Runtimes. Jedes Plugin bringt eigene Routen mit.

Keine Aussage über Betrieb. Antwortzeiten, Ratenbegrenzungen, Feldabdeckung je Endpunkt — nichts davon steckt in einer Routenliste.

Nachmessen

Wer es selbst tun will:

bin/console debug:router --format=json

und dann nach Pfadpräfix zählen — und die Routen nach dem Namensraum ihres Controllers in Kern und Erweiterung trennen, sonst zählt man die eigenen Plugins mit. Der Aufwand liegt bei Minuten, und das Ergebnis ist belastbarer als jede Schätzung.

Wenn aus den Zahlen eine Entscheidung folgen soll, gehört das zu App- und Plugin-Entwicklung.