Best Practice bei der Produktdatenbereitstellung per API-Server

Die Bereitstellung von Produktdaten über REST-Services gehört heute zu den zentralen Anforderungen moderner PIM-Systeme. Damit solche Schnittstellen langfristig tragfähig bleiben und sich ohne hohen Entwicklungsaufwand erweitern lassen, ist ein API-Design notwendig, das flexibel, effizient und sauber strukturiert ist.

Ein zentrales Prinzip dabei ist die dynamische Strukturierung der Produktdaten: Da sich Anforderungen an Produkte, Attribute, Beschreibungen oder Marketinginhalte kontinuierlich verändern, sollte die API nicht von fest im Code hinterlegten Anweisungen abhängen. Stattdessen sollte die Struktur so gestaltet sein, dass sich neue Merkmale, Texttypen oder Produktbeziehungen allein durch Konfiguration oder einen veränderten Datenbestand in die API-Ausgabe integrieren lassen. Auf diese Weise bleiben die REST-Services stabil, während die dahinterliegenden Datenmodelle wachsen oder sich verändern.
Die nachfolgenden Methoden kommen direkt aus der Praxis und haben bereits in vielen Kundenprojekten ebenso flexible wie leistungsfähige Lösungen ermöglicht.

Marktgerechter Zuschnitt

In vielen Unternehmen werden Produkte in unterschiedlichen Zielmärkten eingesetzt. Dabei können regionale rechtliche Rahmenbedingungen, unterschiedliche Sortimentsstrategien oder verschiedene Preis- und Verfügbarkeitsmodelle eine Rolle spielen.

Eine moderne Produkt-API muss daher die Möglichkeit bieten, Produktdaten nach Zielmarkt einzuschränken, sodass Systeme nur die Daten abrufen, die sie tatsächlich benötigen.

Ähnlich verhält es sich mit der Sprachfilterung. Da Produktdaten oft mehrsprachig vorliegen, sollte die API ermöglichen, gezielt bestimmte Sprachversionen abzurufen. Dies dient nicht nur der technischen Effizienz, sondern verhindert auch unnötige Datenübertragung und Speicheraufwand auf Client-Seite.

Eine typische crossbase-API filtert sowohl markt- als auch sprachspezifisch. Die Zusammenhänge werden im "Channel Output Management" erstellt, und jeder Ausgabekanal erhält somit das passende Informationspaket: Sortimente steuern den Artikelumfang, Land-/Sprach-Kombinationen die Inhalte. Ein gutes Beispiel dafür ist die Website unseres Kunden Lamello: https://lamello.com/de/

Nur übertragen, was nötig ist

Für die Synchronisation von Systemen ist es außerdem entscheidend, nicht bei jedem Abruf alle Produktdaten erneut ausliefern zu müssen. Eine zeitbezogene Einschränkung, beispielsweise über einen „Last Modified“-Zeitstempel, erlaubt es, nur jene Produkte bereitzustellen, die seit dem letzten Abruf verändert wurden. Dadurch sinkt nicht nur das Datenvolumen, sondern es wird auch die Performanz der Verarbeitung verbessert, insbesondere bei großen Produktbeständen und regelmäßigen Abrufen.
Ein solches „Delta“ zu ermitteln, ist nur bei sehr umfangreichen Datenmengen sinnvoll. Wir empfehlen es unseren Kunden, die viele Tausend Produkte mit zahlreichen Varianten per API für Shopsysteme und Konfiguratoren bereitstellen.

Individuelle Steuerung

Um eine besonders hohe Flexibilität zu erreichen, empfiehlt sich die Verwendung generischer Parameter für Abfrage- und Steuerungsfunktionen wie Paging, Filter und Sortierung. Indem man solche Funktionen allgemein und nicht individuell für jede neue Anforderung in der API bereitstellt, kann die Schnittstelle ein breites Spektrum an Auswertungs- und Datenausgabeszenarien abdecken, ohne an Übersichtlichkeit zu verlieren oder fortlaufend erweitert werden zu müssen.
Hier ist eine gute Abstimmung mit den Webentwicklern des Zielsystems nötig, beispielsweise des CMS. Insbesondere die Suchfunktionen einer Website profitieren von parametrisierten Abfragen der API.

Produktdaten und Hierarchie trennen

Ein weiterer wichtiger Aspekt ist die Trennung zwischen Produktdaten und Produktstrukturen.
Unter Produktstrukturen ist in diesem Zusammenhang eine hierarchische Gliederung zu verstehen, wie sie beispielsweise für die Navigation einer Website benötigt wird. Solche Strukturen bilden Kategorien, Unterkategorien und Navigationspfade ab und repräsentieren damit nicht die Eigenschaften eines einzelnen Produkts, sondern die organisatorische Einordnung. Da sich diese Gliederungen unabhängig von den Produktdaten weiterentwickeln können, sollten sie separat über die API bereitgestellt werden. Dies ermöglicht es Zielsystemen, ihre Navigations- oder Kategorielogiken systematisch aufzubauen, ohne dass mit jeder Produktabfrage erneut die gesamte Struktur übertragen werden muss.

Aus Ihrem Alltag ist Ihnen das sicher bekannt: Auf der Ebene eines Produkts gibt es häufiger Korrekturen als in der Navigationsstruktur. crossbase trennt übrigens ganz klar zwischen der internen Datenpflege-Struktur und weiteren, für Ihre Ausgabekanäle genutzten Strukturen.

Redundanz bei wiederkehrenden Inhalten verringern

In ähnlichem Maße sollten Stammdaten wie beispielsweise mehrsprachig vorliegende Attributbezeichnungen getrennt von den Produktdaten ausgeliefert werden. Diese Informationen ändern sich vergleichsweise selten und werden von vielen Produkten gemeinsam verwendet. Werden sie separat und per Schlüssel abrufbar bereitgestellt, reduziert das die Größe der einzelnen Produktantworten erheblich und vereinfacht die Verarbeitung auf Empfängerseite.

Ein weiteres Beispiel für Stammdaten sind Wertelisten, die Websites für Suchformulare verwenden. Es wäre ein großer Aufwand, alle möglichen Werte eines Merkmals aus sämtlichen Produkten herauszulesen. Das geht mit einem zentralen Stammdaten-Abruf wesentlich schneller!

Fazit

Eine REST-basierte Produktdaten-API, die all diese Prinzipien berücksichtigt, wird übersichtlich, flexibel, effizient und zukunftssicher. Sie lässt sich extrem schnell erweitern, ohne bestehenden Code verändern zu müssen, unterstützt Integrationen in vielfältige Systemlandschaften und kann problemlos mit wachsenden Datenbeständen und steigenden Anforderungen umgehen.