Wenn Sie in einem benutzerdefinierten Online-Shop eingekauft haben, der nicht wie eine Standardvorlage aussah, ist die Wahrscheinlichkeit groß, dass dahinter eine Headless-Commerce-API die Arbeit erledigt hat. Eine Headless-Commerce-API ist die Schnittstelle, die ein Commerce-Backend bereitstellt, damit jeder Online-Shop Produkte lesen, Warenkörbe erstellen und Bestellungen aufgeben kann, ohne an ein eingebautes Thema gebunden zu sein. Dieser Erklärungsartikel behandelt, was das bedeutet, wie es sich auf Composable Commerce und MACH bezieht und warum Ihr Online-Shop und Ihre Partnerteams von diesem API-Vertrag leben und sterben. Es baut auf der Idee auf, dass Software Headless wird und Ihre API jetzt das Produkt ist.
Was „Headless“ im E-Commerce bedeutet
Traditionelle E-Commerce-Plattformen werden als ein einziges Stück geliefert. Der Produktkatalog, der Warenkorb, der Checkout und die HTML-Seiten, die sie rendern, befinden sich alle im selben System. Sie gestalten es, Sie optimieren es und Sie veröffentlichen es.
Headless Commerce teilt dies in zwei Teile. Das Backend, oft als Commerce-Engine bezeichnet, enthält den Katalog, die Preisgestaltung, den Lagerbestand, den Warenkorb und die Bestelllogik. Das Frontend, Ihr Online-Shop, wird zu einer separaten App, die Sie nach Belieben erstellen. Das Einzige, was sie verbindet, ist eine API.
Der „Kopf“ ist also die Präsentationsebene. Headless zu werden bedeutet, den festen Kopf zu entfernen und den „Körper“, die Commerce-Logik, stattdessen über eine API freizulegen. Eine React-Website, eine native mobile App, ein Smart-Kühlschrank-Bildschirm oder ein Sprachassistent können alle mit demselben Backend kommunizieren, weil sie alle dieselbe API sprechen.
Diese Entkopplung ist der ganze Sinn der Sache. Ihr Frontend-Team wählt sein eigenes Framework und liefert nach eigenem Zeitplan. Das Backend-Team ist für die Commerce-Regeln verantwortlich. Die API ist die Grenze zwischen ihnen.
Der Kompromiss ist, dass Sie mehr Arbeit auf sich nehmen. Eine traditionelle Plattform liefert Ihnen einen funktionierenden Shop sofort. Headless zu werden bedeutet, dass Sie den Online-Shop selbst erstellen und hosten, sodass die Flexibilität mit Ingenieurkosten verbunden ist. Teams entscheiden sich für Headless, wenn ein Standard-Theme nicht das gewünschte Erlebnis bieten kann oder wenn sie mehrere Kanäle von einem Backend aus bedienen möchten.
Headless vs. Composable vs. MACH
Diese drei Begriffe werden oft austauschbar verwendet, beschreiben aber unterschiedliche Bereiche. Hier ist die ehrliche AufschlĂĽsselung.
| Begriff | Was es beschreibt | Umfang |
|---|---|---|
| Headless Commerce | Frontend von einem einzelnen Commerce-Backend entkoppelt, verbunden durch eine API | Ein Backend, ein oder mehrere Frontends |
| Composable Commerce | Der gesamte Stack ist in austauschbare Best-of-Breed-Dienste unterteilt (Katalog, Suche, Zahlungen, PIM, OMS) | Viele unabhängige Dienste zusammengeführt |
| MACH | Ein Satz architektonischer Prinzipien, denen Composable Stacks tendenziell folgen | Eine Philosophie, kein Produkt |
Headless ist der engere Fall. Sie können Headless mit einem monolithischen Backend sein, solange der Online-Shop über eine API damit kommuniziert.
Composable Commerce geht weiter. Anstatt eines Backends stellen Sie unabhängige Dienste zusammen und wählen für jede Aufgabe das beste Tool aus. Die Suche von einem Anbieter, Zahlungen von einem anderen, ein separater Produktinformationsmanager. Jeder ist ein eigener Dienst mit seiner eigenen API, und Sie fügen sie zu einem einzigen Erlebnis zusammen.
MACH ist der Prinzipiensatz hinter den meisten Composable Stacks. Gemäß der MACH Alliance, einer 2020 gegründeten Industriegruppe, steht MACH für Microservices, API-first, Cloud-native SaaS und Headless. Beachten Sie, dass API-first genau in der Mitte sitzt. In einer MACH-Welt ist die API kein Nebenfeature. Sie ist die einzige Möglichkeit, wie die Teile miteinander kommunizieren, was dieselbe Begründung ist, Ihre API als Produkt zu behandeln.
Was eine Headless-Commerce-API tatsächlich freilegt
Die genaue Form variiert je nach Plattform, aber die meisten Headless-Commerce-APIs decken die gleichen Kernaufgaben ab:
- Katalog und Produkte. Produkte, Varianten, Kollektionen und Medien lesen, damit der Online-Shop Listen- und Detailseiten rendern kann.
- Suchen und Stöbern. Den Katalog abfragen, filtern und sortieren.
- Warenkorb und Kasse. Einen Warenkorb erstellen, Positionen hinzufĂĽgen und entfernen, Rabatte anwenden und zur Zahlung ĂĽbergehen.
- Kunden. Anmelden, Konten verwalten und Bestellhistorie verfolgen.
- Lagerbestand und Preise. Lagerbestände und den richtigen Preis für den richtigen Kontext anzeigen.
Einige Plattformen unterteilen diese in eine öffentlich zugängliche Storefront-API und eine separate Admin-API für Back-Office-Arbeiten. Die Storefront-API ist leseintensiv und kundenorientiert. Die Admin-API kümmert sich um Katalogbearbeitungen, Bestellverwaltung und Konfiguration.
Auch das Protokoll ist wichtig. Viele Headless-Commerce-APIs sind GraphQL, was es dem Online-Shop ermöglicht, genau die benötigten Felder in einem einzigen Roundtrip anzufordern. Andere sind REST, und einige Plattformen bieten beides an. Wenn Sie die Vor- und Nachteile abwägen, sehen Sie sich REST vs. GraphQL an.
Die wichtigsten Plattformen
Der Headless-Commerce-Bereich teilt sich grob in SaaS-Engines und Open-Source-Engines auf. Einige Namen, denen Sie begegnen werden:
- commercetools. Ein GrĂĽndungsmitglied der MACH Alliance und eine der meistgenannten Composable Commerce Plattformen. API-first und von Grund auf Cloud-nativ.
- Shopify. Bietet Headless-Builds ĂĽber seine Storefront API an, mit Hydrogen als React-Framework fĂĽr deren Nutzung. Wenn Sie bereits in der Shopify-Welt sind, ist unser Shopify API Tutorial ein guter Ausgangspunkt.
- BigCommerce. Unterstützt den Headless-Modus mit GraphQL Storefront- und Checkout-APIs zusätzlich zu seinem Katalog. Siehe unseren Leitfaden zur Verwendung von BigCommerce APIs.
- Saleor. Eine Open-Source, GraphQL-first Engine, die auf Python und Django basiert.
- Medusa. Eine Open-Source-Engine, die auf Node.js und TypeScript basiert und bei JavaScript-Teams beliebt ist, die die volle Backend-Kontrolle wĂĽnschen.
Überprüfen Sie die plattformspezifischen Details, bevor Sie sich festlegen, da Preise, Hosting-Modelle und API-Abdeckung variieren können. Das Muster ist bei allen gleich: Die Engine legt die Commerce-Logik über eine API frei, und Sie bauen den Kopf.
Warum Teams vom Commerce-API-Vertrag abhängen
Sobald der Online-Shop entkoppelt ist, hört die API auf, nur eine Infrastruktur zu sein, und wird zur Vereinbarung, an der sich alle orientieren. Hier wird Headless Realität.
Ihr Frontend-Team kann eine Produktseite erst veröffentlichen, wenn es die genaue Form einer Produktantwort kennt. Ihre Partnerintegrationen, eine Loyalty-App, ein Steuerdienst, ein Marktplatz-Feed – all das wird an dieselben Endpunkte angeschlossen. Ein mobiles Team konsumiert denselben Vertrag wie das Web-Team. Wenn sich die Form der Antwort ohne Vorwarnung ändert, können alle diese Konsumenten gleichzeitig ausfallen.
Das ist das Risiko und die Chance. Ein klarer, stabiler, gut dokumentierter Commerce-API-Vertrag ermöglicht es unabhängigen Teams, schnell voranzukommen, ohne sich gegenseitig in die Quere zu kommen. Ein vager oder sich ändernder Vertrag macht jede Veröffentlichung zu einem Koordinations-Chaos. Der Vertrag ist das Produkt, daher verdient er die gleiche Sorgfalt wie der Online-Shop selbst, einschließlich Vertragstests, um fehlerhafte Änderungen vor der Veröffentlichung abzufangen.
Die Versionierung gehört auch dazu. Wenn Sie eine Produktantwort ändern oder ein Feld umbenennen müssen, können Sie nicht einfach den Endpunkt bearbeiten und hoffen. Konsumenten, die Sie nicht kontrollieren, lesen ihn. Daher behandeln Headless-Teams den Vertrag als eine öffentliche Zusage: additive Änderungen, wo möglich, klare Deprecations-Fristen und Tests, die alles, was eine Integration eines Partners beeinträchtigen könnte, kennzeichnen, bevor es veröffentlicht wird.
Wo Apidog passt
Apidog betreibt Ihren Shop nicht. Es ist keine Commerce-Engine, kein CMS oder Gateway, und es macht Ihren Stack weder headless noch composable. Was es tut, ist die API-First-Säule von alldem zu besitzen: die Ebene, auf der Sie den Vertrag entwerfen, testen, simulieren und dokumentieren, von dem alles andere abhängt.
Das lässt sich sauber auf die Headless-Commerce-Arbeit übertragen:
- Entwerfen Sie zuerst den Vertrag. Modellieren Sie die Storefront- oder Admin-API als OpenAPI-Spezifikation in Apidog, bevor Code existiert, damit Frontend und Backend sich im Voraus ĂĽber die Form einig sind.
- Simulieren Sie, bevor das Backend bereit ist. Starten Sie einen Mock-Server aus der Spezifikation, damit Ihr Storefront-Team gegen realistische Produkt- und Warenkorbantworten entwickeln kann, während die Commerce-Engine noch eingerichtet wird. Das ist das praktisch umgesetzte Versprechen der Entkopplung, und Sie können mehr in unserem Mock-API-Erklärungsartikel lesen.
- Testen Sie den Vertrag in CI. Die Apidog CLI fĂĽhrt Ihre API-Tests ohne GUI aus, eine Headless-TestausfĂĽhrung, die in eine Pipeline passt. Es ist eine echte konzeptionelle Ăśbereinstimmung mit Headless Commerce: kein Frontend erforderlich, nur die ĂśberprĂĽfung des Vertrags.
- Dokumentieren Sie es fĂĽr Partner. Automatisch generierte, interaktive Dokumente bieten Ihren Storefront- und Partnerteams eine einzige Quelle der Wahrheit fĂĽr die API, gegen die sie integrieren.
Für einen tieferen Einblick, warum dies wichtig ist, sobald die API die einzige Schnittstelle wird, siehe Software wird headless und Ihre API ist jetzt das Produkt. Wenn Sie den Workflow ausprobieren möchten, laden Sie Apidog herunter und importieren Sie eine bestehende Spezifikation.
Häufig gestellte Fragen
Ist Headless Commerce dasselbe wie Composable Commerce?
Nein. Headless Commerce entkoppelt den Online-Shop über eine API von einem Commerce-Backend. Composable Commerce geht weiter und fügt viele unabhängige Best-of-Breed-Dienste, jeder mit seiner eigenen API, zu einem einzigen Erlebnis zusammen. Jeder Composable Stack ist headless, aber ein headless Setup mit einem monolithischen Backend ist nicht unbedingt composable.
Benötige ich GraphQL für eine Headless-Commerce-API?
Nein. GraphQL ist üblich, weil es dem Online-Shop ermöglicht, genau die benötigten Felder in einem Aufruf anzufordern, was sich gut für die Produkt- und Warenkorb-Darstellung eignet. Aber viele Headless-Commerce-APIs verwenden REST, und einige Plattformen bieten beides an. Das Protokoll ist weniger wichtig als die Stabilität und Dokumentation des Vertrags.
Kann ich eine Headless-Commerce-API testen, bevor das Backend erstellt wird?
Ja, und das ist einer der Hauptgründe, design-first vorzugehen. Wenn Sie den API-Vertrag als Spezifikation modellieren, können Sie einen Mock-Server generieren, der realistische Antworten liefert. Ihr Storefront-Team entwickelt und testet gegen den Mock, während die Commerce-Engine noch in Arbeit ist, und wechselt später zu den echten Endpunkten.
Was ist die MACH Alliance?
Die MACH Alliance ist eine 2020 gegründete Industriegruppe, die offene, Best-of-Breed-Technologie-Stacks fördert, die auf Microservices-, API-first-, Cloud-native SaaS- und Headless-Prinzipien basieren. Anbieter wie commercetools sind Gründungsmitglieder. MACH ist ein Satz architektonischer Prinzipien, kein einzelnes Produkt, das man kaufen kann.
Der Vertrag ist der Shop
Headless Commerce verlagert den Wert vom Theme auf die API. Sobald der Online-Shop entkoppelt ist, ist die Commerce-API das, worauf Ihre Frontend-, Mobil- und Partnerteams tatsächlich aufbauen. Composable Commerce und MACH treiben dies weiter voran, indem sie API-first zu einem Kernprinzip machen und nicht nur zu einem Nice-to-have.
Nichts davon hängt von Apidog ab, aber die Qualität des Vertrags profitiert von einem Ort, an dem er entworfen, simuliert, getestet und dokumentiert werden kann. Wenn Ihr Headless-Projekt dorthin geht, bietet Ihnen Apidog diese Ebene, ohne so zu tun, als wäre es die zugrunde liegende Commerce-Engine.