An API-first Approach to Content Creation, Management and Routing

Unter den Anforderungen für die Picturepark Content Plattform war auch der so genannte „API-first“-Ansatz gelistet. Das bedeutet, dass das API modern sowie einfach zu verstehen und zu nutzen ist und den vollständigen Zugriff auf das System und alle darin enthaltenen Inhalte ermöglichen soll.

Bei praktisch allen etablierten Digital Asset Management-, Content Management- und anderen ähnlichen Systemen wurden APIs erst dann hinzugefügt, nachdem das System mit einem „UI- first“-Ansatz entwickelt worden war. Dabei ist der API Zugriff meist nur auf eine Teilmenge der Systemfunktionen möglich. APIs aber, die den Entwicklern absolute Freiheit in der Interaktion mit bestehenden Host-Systemen ermöglichen, sind eher selten.

Für die Ingenieure der Picturepark Content Plattform war das Entwicklungsziel klar definiert: Machen wir es so, dass es uns gefällt – dann wissen wir, dass es auch andere Entwickler gerne damit arbeiten.

Wie wurde „API-first“ eine solche revolutionäre Entwicklung?

Bevor der Begriff „as a Service“ durch die Technologiebranche so umfassend genutzt wurde, dachten wir weniger an ein System, das ausschließlich als Dienst genutzt wurde – alles war damals eigenständiger.

Heute ist der Begriff gebräuchlich für Systeme, deren einziger Zweck darin besteht, Daten oder Datenverarbeitung für andere Systeme zur Verfügung zu stellen. Mobile Apps beispielsweise sind oft mit Backend-Systemen verbunden, die ihnen Informationen zur Verfügung stellen, die sie wiederum ihren Benutzern bereitstellen.

Die am weitesten verbreiteten service-basierten Systeme sind solche, die als Software-as-a-Service, kurz SaaS, bezeichnet werden. Dieser Begriff beschreibt eine vollständige Software-Applikation, die auf einem entfernten System gehostet wird. SaaS ist für die Nutzer einfach zu verstehen, weil sie einen Browser öffnen, mit einem URL verbinden und die Applikation erscheint. Dies war schon mit Picturepark 8 möglich, das seit dem Jahr 1998 als Service zur Verfügung steht.

Ausgehend von dieser Basis entwickelten sich Platform-as-a-Service, Infrastructure-as-a-Service und so viele andere Konzepte, so dass ich hier gar nicht den Anschein erwecken möchte, alle zu kennen. Aber alle haben ein Merkmal gemeinsam – ein Backend-System, auf das über ein API zugegriffen wird, und das den aufrufenden Systemen etwas zur Verfügung stellt.

In jüngerer Zeit kam „Content-as-a-Service“ hinzu. Dabei gibt es wiederum ein Backend-System, das anfordernden Systemen Inhalte zur Verfügung stellt. So genannte „Headless CMS“ sind ein gerade populäres Beispiel dafür, es gibt aber auch noch andere Systeme. Börsen- oder Wetterdaten sowie Newsfeeds können ebenfalls als Content-as-a-Service-Systeme angesehen werden, da die Quellinformationen von einem entfernten System stammen.

Der Vorteil liegt darin, dass auf die Quellinhalte beliebig oft von einer beliebigen Anzahl von Stellen zugegriffen werden kann. Denken Sie zum Beispiel nur an all die Stellen, an denen Du täglich die jeweiligen Schlusskurse von Apple, Google und anderen sehen kannst. Es gibt eine Quelle für diese Daten – die Börse. Die Werte werden aber an Tausenden von Orten in der Regel innerhalb von Sekunden veröffentlicht – ganz einfach, weil die Daten über APIs als Service bereitgestellt werden an alle Systeme, die sie benötigen.

Was hat das mit Content Management zu tun?

OK, in einem viel kleineren Maßstab gibt es einen Bedarf für einzelne Unternehmen, ihre eigenen Inhalte zu kreieren und als Service zur Verfügung zu stellen. Das war der Beginn von Digital Asset Management, da die Unternehmen folgendes realisierten: Wenn sie eine Kopie ihres Logos an einem Ort speichern und von dort vorhalten, werden nicht überall Variationen des Logos auftauchen und sie können verfolgen, wer es heruntergeladen hat. Und wenn sie das Logo tatsächlich ändern wollen , dann müssten sie das nur an einem Ort tun.

Es gab eine Zeit, da war die einzige Möglichkeit, das Logo im DAM zu nutzen, es herunterzuladen und dann auf die Website oder an all die Orte hochzuladen, wo immer es benötigt wurde. Dann aber erhielten DAMs die Fähigkeit, Links bereitzustellen, über die das Logo „on-the-fly“ angezeigt werden konnte. Die Nutzer können den Link in einer Webseite verwenden und beim Laden der Seite erscheint die jeweils neueste Version des Logos.

Das war eine richtungsweisende Neuerung im Content-Bereich – so lange, bis sich die Art und Weise der Handhabung und Nutzung von Inhalten änderte. Heute sind viele der Inhalte, mit denen wir interagieren, nicht mehr dateibasiert. Und die meisten sind nicht einfach nur ein Logo.

Denke nur an Urheberrechtshinweise, Richtlinien in Unternehmen oder einfach nur die Büroadresse. Wo ist die Master-Datei der Urheberrechtshinweise Ihres Unternehmens? Wahrscheinlich weiß das niemand, da viele Kopien dieses Inhalts unterwegs sind. Der Fußbereich Ihrer Website enthält Ihren Urheberrechtsvermerk, aber er ist wahrscheinlich nicht der Link zur eigentlichen Master-Datei dieser Information. Wenn der Vermerk aktualisiert wird, muss er manuell überall dort geändert werden, wo er verwendet wurde.

Wenn Du „Masterdata Management“ googelst, wirst Du Systeme finden, die als einzige Quelle umfassender Datenbestände wie Produktkatalogen, Lagerhaltungsdaten und anderem entworfen wurden. Aber diese Systeme sind zu viel des Guten für die kleineren Inhalte wie eben Urheberrechtshinweisen, aber auch für die Lebensläufe des Managements und ähnlichen Dingen.

Die Picturepark Content Plattform ist eine großartige Lösung für das Management dieser „Datenschnipsel“, weil es so einfach ist, Datensätze für diese Inhalte anzulegen und zu verwalten. Diese sind nicht nur zugreifbar und editierbar über das API – das System mit dem API wurde so entwickelt, dass andere Systeme lose oder fest verbunden werden können, ohne dass dafür die Beherrschung komplexer (und meist überkommener) Technologien notwendig ist.

Picturepark kann sogar Stammdaten aus vorgelagerten Systemen beziehen und diese mit anderen Daten kombinieren, die dann als für das API verwertbarer Datenblock an nachgelagerte Systeme übergeben werden können. So können zum Beispiel Ihre rohen Produktdaten von einem Product Information Manager (PIM) oder Enterprise Resource Manager (ERP) kommen und mit Bildern und Videos kombiniert werden, die in Picturepark verwaltet werden. All dies wird dann über einen einzigen API-Aufruf an das Verzeichnis einer Website oder an eine mobile App geleitet.

Der Nutzen liegt also nicht im bloßen Vorhandensein eines APIs, sondern in einem guten API verbunden mit einem System, das Quellinhalte von den Orten abstrahieren kann, an denen diese Inhalte verwendet werden. Das Gesamtsystem kann Inhalte aus verschiedenen Quellen kombinieren und diese dann dorthin routen, wo immer sie benötigt werden.

Kannst Du eine grundlegende Erklärung für diese Kombination und “Routing” von Inhalten geben?

Dies mag als ziemlich komplexes Konzept erscheinen, es gibt aber zwei einfache Beispiele aus der Praxis. Nimm beispielsweise ein Word-Dokument, das Ihren Text beinhaltet, Bilder aus Photoshop und Tabellen aus Excel. Während Du in dem Dokument arbeitest, bist Du Dir bewusst, dass jeder dieser Inhalte aus verschiedenen Quellen stammt. Wenn Du das Dokument aber an den Drucker weiterleiten, ist es zu einem einzigen Stück Inhalt geworden, das alles enthält. Die Personen, die das Dokument lesen, ahnen nicht, dass die Bilder in einer Applikation und die Diagramme in einer anderen erstellt wurden – sie sehen einfach nur ein Dokument.

Es war unser Ziel, dass die Content Plattform zu einer Drehscheibe wird, über die Inhalte gesammelt, kombiniert und an Websites, mobile Apps und andere Systeme übergeben werden können, die sie vielleicht weiter verarbeiten. In gewisser Hinsicht ist das nicht weit entfernt von dem, was als „Cross-Media-Publishing“ idealisiert wurde. Das Problem war, dass diese Systeme nie sehr benutzerfreundlich wurden, sie waren komplex und monolithisch.

Je mehr das Verständnis für die Leistungsfähigkeit des „headless Access“ zu Contentsystemen zunimmt, desto mehr werden die Vorteile der Trennung der Rohinhalte von den Ausgabekanälen realisiert, über welche die Inhalte konsumiert werden. Viele Nutzer fragen sich dann, welche Systeme sie dafür nutzen können. Hier zeigt die Content Plattform ihren Wert.

Also wird die Content Plattform ein System sein, das mehr von anderen Systemen als von Menschen genutzt wird?

Nicht im Mindesten! Die Content Plattform hat eine attraktive Benutzeroberfläche, über die das Arbeiten mit all diesen Inhalten wirklich Spaß macht – selbst auf einem Smartphone. Du kannst das System als eigenständiges Contentsystem nutzen, ähnlich, wie Du Picturepark 8 heute verwendest. Es bietet Digital Asset Management-Funktionen wie Uploads, die Bearbeitung von Metadaten, Downloads und Sharing – Du kannst es also einfach auch so benutzen.

Wir sprechen von API-first und Content-as-a-Service, weil wir glauben, dass unsere Kunden sehr bald danach fragen werden. Tatsächlich haben wir bereits seit längerem entsprechende Anfragen erhalten. So werden unsere Kunden die Content Plattform direkt nutzen können – ohne DAM-Funktionalität zu verlieren, welche die meisten „headless“ CMS nicht bieten. Du wirst in der Lage sein, die Plattform mit anderen Systemen, Services und Apps zu verbinden.

Welche Tools werden Entwicklern für die Content Plattform zur Verfügung stehen?

Wir werden ein REST API für die Content Plattform bereitstellen, das mehrere API-Endpunkte umfasst, um alle Bereiche abzudecken. Wir verwenden dafür das Swagger API-Framework. Wir werden außerdem über Github eine Dokumentation, Beispiele und andere Ressourcen zur Verfügung stellen. Wir planen, nicht nur das SDK, sondern auch einige unserer Connectoren als OpenSource zur Verfügung zu stellen, daher ist Github eine gute Lösung.

Sehr umfassende SDK Code-Beispiele werden in Angular JS, C# und Java zur Verfügung stehen. Wir arbeiten außerdem an Frameworks für die Integration, die es Entwicklern ermöglichen, sich in ausgewählte Bereiche der Oberfläche der Content Plattform einzuloggen. Mehr dazu werden wir im Laufe des Jahres ankündigen.

Wir überarbeiten auch unser Entwicklerprogramm und stellen API/SDK-Consultants ein. Diese sind selbst Entwickler – so können wir besser auf die Bedürfnisse der Entwickler reagieren und sind besser vorbereitet, sie nicht nur in Bezug auf den Code, sondern auch im Hinblick auf die geschäftlichen Aspekte zu beraten.

Generell wird die Content Plattform ein extrem entwicklerfreundliches System sein – sowohl in Bezug auf die verwendeten Technologien als auch in der Art, wie das API ermöglicht, mit wenig Aufwand optimalen Code zu schreiben. Ich jedenfalls habe sehr viel Spaß damit.

Andere Interviews in dieser Serie:

• David Diamond, Direktor von Global Marketing bei Picturepark, spricht darüber, ob Produkte wie die Picturepark Content Platform der Tod des Digital Asset Management sein werden. Lesen Sie dieses Interview »
• Olivia Schütt, Product Manager bei Picturepark, erläutert, wie die Content Plattform entstanden ist. Lesen Sie dieses Interview »
• Urs Brogle, Direktor für Engineering bei Picturepark, berichtet über die Entwicklung der Content-Plattform – welche Technologieentscheidungen getroffen wurden und die Herausforderungen, denen das Team ausgesetzt war. Lesen Sie dieses Interview »

Erfahren Sie mehr über die Picturepark Content Plattform »