Automatisiertes Onboarding von Produktdaten mit Onedot API 2.0

Wir freuen uns, unseren Anwendern die nächste Generation der Onedot-API vorstellen zu können, ein umfassendes Set von Operationen, um das Onboarding von Produktdaten maximal zu automatisieren, von der Übertragung von Datendateien wie Produktdatenkatalogen über das Einrichten und Ausführen von Onboarding-Jobs, das Zuweisen von Feedback-Aufgaben, das Abrufen von Leistungsstatistiken und Schlüsselmessungen bis hin zum Herunterladen der onboarded Produktdaten im richtigen Format und in der richtigen Struktur: konsumierbare Daten!

Seit geraumer Zeit verwenden unsere Kunden unsere Onedot-API der ersten Generation, die auf dem OpenAPI 2.0-Standard basiert, einem weit verbreiteten Ansatz zur Öffnung von REST (Representational State Transfer), RESTful oder REST-ähnlichen APIs für die Welt. Eine Reihe von Open-Source-Tools, die auf den OpenAPI 2.0- und 3.0-Spezifikationen basieren, helfen Ihnen bei der Entwicklung, Erstellung, Dokumentation und Nutzung von REST-APIs. Browser-basierte Editoren ermöglichen Ihnen das Schreiben der OpenAPI-Spezifikationen, andere Tools stellen OpenAPI-Spezifikationen als interaktive API-Dokumentation dar oder generieren sogar Client-Bibliothekscode für Ihre API in über 40 Sprachen!

Der OpenAPI 2.0-Standard fördert einen Design-First-Ansatz: Mittels Codegenerierung wird eine gültige API-Spezifikation in serverseitige Stubs umgewandelt und der Server-Login mit wenigen Zeilen Code implementiert. Während sich dieser Ansatz in vielen Fällen gegenüber alternativen API-Designs als überlegen erweist, bringt die irgendwie enge Beziehung zum REST-Paradigma auch einige Nachteile mit sich:

• Leistungsstarke SPAs (Single Page Applications) wie die Onedot-App interagieren mit vielen Backend-Diensten der Plattform, was zu einem erheblichen Netzwerkverkehr führt.
• Clients einer REST-API müssen in der Regel eine vordefinierte Form der zurückgegebenen Ergebnisse akzeptieren, was zu einer höheren Bandbreitennutzung und einer höheren Komplexität des API-Clients führt.
• Die Abfrage komplexer Objekthierarchien wird unnötig schwer und ineffizient, da selbst für einfache Abfragen mehrere Serveraufrufe erforderlich sind.
• Micro-Service-Anwendungsarchitekturen umfassen das Konzept mehrerer Datenspeicher, was für die API-Clients eine unnötige Belastung bei der Verarbeitung von Datenbeziehungen bedeutet.

Auf der Grundlage dieser Beobachtungen haben wir GraphQL als eine modernere und leistungsfähigere Alternative bewertet, die alle Vorteile des OpenAPI-Standards nutzt und gleichzeitig die beiden klassischen REST-Beschränkungen, nämlich Datenfilter und Datenbeziehungen, überwindet. Diese Schwachstellen zwingen REST-Clients dazu, immer eine vollständige Nutzlast als Antwort zu erhalten und mehrere Datenspeicher separat anzusprechen, was Bandbreite beansprucht und die Antwortzeit einer Anwendung erhöht.

GraphQL ist im Wesentlichen keine API, sondern eine Datenabfrage- und -manipulationssprache für APIs. Ursprünglich wurde sie von Facebook entwickelt und als Open Source zur Verfügung gestellt. Sie löst das Problem des nicht optimierten Datenflusses zwischen mobilen Anwendungen oder SPAs und einem Backend, seien es Microservices, serverlose Endpunkte oder ein traditioneller Monolith. GraphQL ist eine Syntax, die die Art und Weise beschreibt, wie Daten vom Server abgefragt werden. Der Hauptunterschied von GraphQL im Vergleich zu traditionellen REST-APIs besteht darin, dass das Antwortformat in der Abfrage selbst übermittelt und vom Client und nicht vom Server definiert wird. GraphQL-APIs sind in Form von Typen und Feldern organisiert, nicht in Form von Endpunkten. Der Zugriff auf den vollen Funktionsumfang Ihrer Daten erfolgt von einem einzigen Endpunkt aus, und zwar sprachunabhängig.

Ähnlich wie bei OpenAPI ist der Kerngedanke bei der Verwendung von GraphQL eine Schemaspezifikation, die die Datenstruktur streng definiert und regelt, wie auf Daten zugegriffen werden kann. Es gibt zwei grundlegende Arten von GraphQL-Operationen:

• Abfragen: Ermöglicht Clients das Lesen oder Abrufen von Daten aus dem Backend
• Mutationen: Ermöglicht es den Kunden, den Zustand der Daten im Backend zu ändern

Die strikte Trennung in Abfragen und Mutationen folgt dem CQS-Prinzip (Command-Query Separation), das im Wesentlichen erzwingt, dass Operationen entweder ein Befehl sein müssen, der eine Aktion ausführt, oder eine Abfrage, die Daten an den Aufrufer zurückgibt, aber nicht beides. Mit anderen Worten: Das Stellen einer Frage sollte die Antwort nicht verändern. Dies hat nicht nur eine vereinfachende Wirkung auf API-Clients oder Anwendungen im Allgemeinen, sondern macht auch Zustände (über Abfragen) und Zustandsänderungen (über Befehle) verständlicher. Um die Serveraufrufe bei der Interaktion mit einem GraphQL-Endpunkt zu minimieren, gilt es als gute Praxis, Mutationen den aktualisierten Zustand (nach der Zustandsänderung) an den API-Client zurückgeben zu lassen, wodurch ein weiterer Dienstaufruf zum Abrufen des neuesten Zustands eingespart wird.

In diesem Sinne kündigen wir die sofortige Verfügbarkeit der Onedot API 2.0 an, einem GraphQL-basierten Endpunkt zur Automatisierung aller Aspekte der Onedot-Plattform! Sehen Sie sich unsere umfassende API-Referenzdokumentation an, machen Sie eine Testfahrt in unserem API Playground und verwenden Sie Ihren bevorzugten GraphQL-Client, um nahtlos mit Onedot zu interagieren. Die meisten API-Abfragen und -Mutationen erfordern eine Authentifizierung, bei der ein API-Schlüssel über den HTTP X-API-Key-Header mit jeder Anfrage übergeben werden muss.

Um mit Ihren ersten Abfragen zu beginnen, fordern Sie einen API-Schlüssel an, indem Sie uns unter support@onedot.com kontaktieren . Wir freuen uns zu hören, wie Sie die Onedot-API nutzen. Schreiben Sie uns einfach und lassen Sie uns Ihr Feedback wissen.