Definition: Eine API (Application Programming Interface) ist eine fest definierte Schnittstelle, über die ein Softwaresystem Daten oder Funktionen für andere Systeme bereitstellt. Die API legt fest, welche Anfragen erlaubt sind, in welchem Format Daten übertragen werden und wie sich ein aufrufendes System authentifiziert. Im Web sind das meist HTTP-Schnittstellen mit JSON als Datenformat.
Im B2B-Maschinenbau verbinden APIs 3D-Inhalte mit den Systemen, in denen Produktwissen entsteht: ERP (Artikel, Preise, Verfügbarkeit), PIM (Produktdaten, Texte, Varianten), CAD/PLM (Geometrie, Stücklisten) und CRM (Kunden, Angebote, Leads). So bleiben 3D-Modelle, Konfiguratoren und AR-Anwendungen automatisch auf dem Stand der Stammdaten.
Vorteil: Daten werden einmal gepflegt und in allen Kanälen genutzt, statt sie manuell zu kopieren.
Englisch: API (Application Programming Interface)
Deutsch: Programmierschnittstelle, Schnittstelle
Funktionsweise
Anfrage und Antwort
Bei einer Web-API läuft jeder Aufruf nach demselben Muster ab:
- Client sendet Anfrage: z. B. “Gib mir alle Varianten von Maschine X” an eine definierte Adresse (Endpoint).
- Server prüft Berechtigung: API-Schlüssel oder Token zeigen, wer anfragt und was er darf.
- Server verarbeitet: liest Daten aus der Datenbank oder löst eine Aktion aus.
- Server antwortet: mit Statuscode (z. B. 200 für Erfolg, 404 für “nicht gefunden”) und Daten, meist im JSON-Format.
Vertrag statt Absprache
Eine API ist ein Vertrag zwischen Systemen. Solange sich beide Seiten an die Beschreibung halten, können sie unabhängig voneinander weiterentwickelt werden. Formale Beschreibungen wie die OpenAPI-Spezifikation machen diesen Vertrag maschinenlesbar: Aus ihr lassen sich Dokumentation, Testwerkzeuge und Client-Code erzeugen.
API-Architekturen im Vergleich
REST
REST (Representational State Transfer) ist der verbreitetste Stil für Web-APIs. Daten werden als Ressourcen mit eigener URL abgebildet, etwa /maschinen/123/varianten. HTTP-Methoden beschreiben die Aktion: GET liest, POST legt an, PUT oder PATCH ändert, DELETE löscht.
Stärke: Einfach, gut cachebar, von fast jedem System unterstützt.
GraphQL
Bei GraphQL fragt der Client genau die Felder an, die er braucht, auch über mehrere verknüpfte Objekte hinweg, in einer einzigen Anfrage. Für einen 3D-Konfigurator kann das bedeuten: Maschine, Optionen, Preise und Modell-URLs in einem Aufruf.
Stärke: Weniger Anfragen, keine überflüssigen Daten. Aufwand: Caching und Zugriffskontrolle sind komplexer als bei REST.
Webhooks
Webhooks drehen die Richtung um: Statt regelmäßig nachzufragen (“Hat sich etwas geändert?”), meldet das Quellsystem ein Ereignis aktiv per HTTP-Aufruf an eine hinterlegte Adresse. Beispiel: Im PIM wird eine Produktbeschreibung geändert, der Webhook löst die Aktualisierung im 3D-Viewer aus.
Wichtig: Webhook-Empfänger sollten die Signatur der Nachricht prüfen (meist per HMAC), damit nur echte Ereignisse verarbeitet werden.
| Ansatz | Richtung | Typischer Einsatz |
|---|---|---|
| REST | Client fragt an | Stammdaten lesen und schreiben |
| GraphQL | Client fragt gezielt an | Frontends mit vielen verknüpften Daten |
| Webhooks | Server meldet Ereignis | Synchronisation bei Änderungen |
Integrationsmuster für 3D-Inhalte
Punkt-zu-Punkt
Jede Anwendung spricht direkt mit jedem Quellsystem. Das ist schnell umgesetzt, wird aber bei vielen Systemen unübersichtlich: Ändert sich die ERP-Schnittstelle, müssen alle angebundenen Anwendungen nachziehen.
Zentrale Integrationsschicht
Eine Middleware oder Integrationsplattform sammelt Daten aus ERP, PIM, CAD und CRM, vereinheitlicht sie und stellt sie über eine eigene API bereit. Web-Viewer, Kiosk-Anwendung und AR-App greifen nur auf diese Schicht zu. Änderungen in einem Quellsystem werden an einer Stelle angepasst.
Ereignisgesteuert
Systeme veröffentlichen Änderungen als Ereignisse (über Webhooks oder Message-Broker), interessierte Anwendungen reagieren darauf. Das entkoppelt die Systeme zeitlich und eignet sich besonders für die Synchronisation großer Produktportfolios.
Praxis: Viele Unternehmen kombinieren die Muster, etwa eine zentrale Schicht für Stammdaten und Ereignisse für Änderungen an CAD-Ständen.
B2B-Anwendungen
Vertrieb: Konfigurator mit Live-Daten
Ein 3D-Produktkonfigurator zeigt eine Verpackungsmaschine im Browser. Über die ERP-API kommen Preise und Lieferzeiten, über die PIM-API Optionstexte. Ist die Konfiguration fertig, legt eine CRM-API automatisch ein Angebot oder einen Lead an. Der Vertrieb sieht im CRM, welche Variante der Kunde gewählt hat.
Messe: Inhalte zentral steuern
Kiosk-Terminals, Tablets und Bildschirme auf dem Messestand beziehen ihre 3D-Inhalte über eine API aus einem zentralen System. Neue Exponate oder geänderte Texte werden einmal gepflegt und erscheinen auf allen Geräten. Besucherkontakte aus der Kiosk-Anwendung landen per API direkt im CRM.
Service: Ersatzteile im 3D-Modell
Ein Techniker wählt im 3D-Modell einer CNC-Fräse ein Bauteil aus. Über die Bauteil-ID fragt die Anwendung beim ERP Artikelnummer, Lagerbestand und Preis ab und erzeugt bei Bedarf eine Bestellung. Das funktioniert im Web, auf dem Tablet und in einer Augmented-Reality-Ansicht mit derselben Schnittstelle.
Schulung: Trainingsdaten zurückmelden
VR- oder Web-Schulungen melden Ergebnisse (abgeschlossene Module, Fehler, Dauer) über eine API an das Lernmanagementsystem oder die Personalabteilung. So lässt sich nachweisen, wer an welcher Maschine geschult wurde.
Design Review: CAD-Stand automatisch übernehmen
Wird im PLM-System eine neue Konstruktionsversion freigegeben, löst ein Webhook die Konvertierung in der 3D-Pipeline aus. Das Review-Team sieht im Browser oder in Virtual Reality immer den aktuellen Stand, ohne Dateien per E-Mail zu verschicken.
Sicherheit und Betrieb
- Authentifizierung: API-Schlüssel für einfache Server-zu-Server-Verbindungen, OAuth 2.0 mit kurzlebigen Tokens für Zugriffe im Namen von Nutzern.
- Minimale Rechte: Ein Konfigurator braucht Lesezugriff auf Preise, aber keinen Schreibzugriff auf das ERP.
- Verschlüsselung: Übertragung ausschließlich über HTTPS (TLS).
- Ratenbegrenzung: Server begrenzen Anfragen pro Zeitraum und antworten bei Überschreitung mit Statuscode 429.
- Versionierung: Neue API-Versionen laufen parallel zur alten, damit bestehende Integrationen nicht brechen.
- Datensicherheit und Datenschutz: CAD-Originaldaten und Kundendaten nur so weit freigeben, wie der Anwendungsfall es erfordert.
Häufig gestellte Fragen (FAQ)
Was ist der Unterschied zwischen API und Schnittstelle?
Im Deutschen werden beide Begriffe oft synonym verwendet. Genau genommen ist “Schnittstelle” der Oberbegriff, auch für Hardware oder Dateiaustausch. Eine API ist eine Schnittstelle zwischen Programmen mit festgelegten Aufrufen und Datenformaten.
REST oder GraphQL: Was ist für 3D-Anwendungen besser?
REST reicht für die meisten Integrationen und wird von ERP- und PIM-Systemen breit unterstützt. GraphQL lohnt sich, wenn ein Frontend viele verknüpfte Daten aus mehreren Quellen braucht, etwa ein Konfigurator mit Optionen, Abhängigkeiten und Preisen. Beide lassen sich kombinieren.
Werden 3D-Modelle selbst über die API übertragen?
Meist nicht direkt. Die API liefert Metadaten und eine Adresse, unter der die Modelldatei (z. B. glTF oder USDZ) abgerufen wird, oft über ein Content Delivery Network. So bleiben API-Antworten klein und die Modelle werden effizient zwischengespeichert.
Wann brauche ich Webhooks statt regelmäßiger Abfragen?
Wenn Änderungen zeitnah ankommen sollen und selten passieren. Regelmäßige Abfragen (Polling) erzeugen viel Last, obwohl sich meist nichts geändert hat. Webhooks melden nur echte Ereignisse. Für die Ausfallsicherheit sollte der Empfänger verpasste Ereignisse trotzdem nachträglich abgleichen können.
Was sollte eine gute API-Dokumentation enthalten?
Eine maschinenlesbare Beschreibung (z. B. OpenAPI), Beispiele für typische Aufrufe, Erklärung der Authentifizierung, Fehlercodes, Ratenlimits und eine Übersicht der Versionen mit Änderungen. Eine Testumgebung (Sandbox) erleichtert IT-Teams die Integration erheblich.
Branchenstandards und Technologien
- OpenAPI Specification – Standard zur Beschreibung von HTTP-APIs (aktuell Version 3.2)
- GraphQL Specification – Spezifikation der GraphQL Foundation
- RFC 9110 – HTTP Semantics – Grundlage von Methoden und Statuscodes
- RFC 6749 – OAuth 2.0 – Autorisierung für API-Zugriffe
- Standard Webhooks – Offene Konventionen für signierte Webhooks
- Verwaltungsschale, API (IDTA) – Standardisierte REST-API für industrielle Digital Twins
Verwandte Themen
Integration: - ERP – Warenwirtschaft und Stammdaten - PIM – Produktinformationsmanagement - PLM / CAD – Konstruktionsdaten - CRM – Kundenbeziehungen - Middleware – Vermittlungsschicht zwischen Systemen
API-Technologien: - REST – Ressourcenbasierte Web-APIs - GraphQL – Abfragesprache für APIs - Webhooks – Ereignisbenachrichtigung - JSON – Datenformat - OAuth 2.0 – Autorisierung - API-Gateway – Zentrale Steuerung von Zugriffen
3D-Inhalte: - 3D-Modell – Geometrische Basis - 3D-Pipeline – Von CAD zu Echtzeit-3D - 3D-Produktkonfiguratoren – Konfiguration im Browser - WebGL – 3D im Browser - USDZ – 3D-Format für Apple-Plattformen - OBJ – Einfaches Austauschformat
Vernetzte Systeme: - IoT – Vernetzte Maschinen - Digital Twin – Digitaler Zwilling - OPC UA – Industrieller Datenaustausch
Sicherheit: - Datensicherheit – Schutz von Daten und Systemen - Datenschutz – Umgang mit personenbezogenen Daten
