REST API
Auch: RESTful API · REST-Schnittstelle · RESTful Webservice
Eine REST API ist eine Programmierschnittstelle, die über das Web-Protokoll HTTP Daten austauscht: Jede Ressource wie Artikel, Auftrag oder Kunde hat eine eigene Adresse (URL) und wird mit Standardbefehlen gelesen oder verändert. Im ERP verbindet die REST API das System mit Shop, Marktplatz, Payment und Versand.
Eine REST API (Representational State Transfer) ist ein weit verbreiteter Baustil für Programmierschnittstellen, bei dem Systeme über das normale Web-Protokoll HTTP Daten austauschen. Der Kerngedanke: Jede Information ist eine „Ressource“ – ein Artikel, ein Auftrag, ein Kunde – und jede Ressource ist über eine eigene, eindeutige Adresse (URL) ansprechbar. Ein anderes System greift auf diese Adresse zu und erhält die Daten meist im schlanken Format JSON zurück oder verändert sie. REST ist damit kein Produkt und keine Software, sondern ein Satz von Konventionen, an die sich Anbieter halten, damit ihre Schnittstellen einfach, vorhersehbar und breit nutzbar sind.
Im ERP-Umfeld ist die REST API heute der Standardweg, über den ein Warenwirtschafts- oder ERP-System mit der übrigen Systemlandschaft spricht: mit dem Onlineshop, mit Marktplätzen, mit Zahlungs- und Versanddienstleistern sowie mit der Buchhaltung. Weil REST auf denselben Mechanismen wie das Web selbst aufsetzt, lässt es sich mit nahezu jeder Programmiersprache und jedem Tool ansprechen. Das macht REST-APIs zur meistgenutzten Integrationsform moderner Cloud-ERP-Systeme.
Auf einen Blick
- REST = Architekturstil für Web-Schnittstellen über das Protokoll HTTP
- Jede Ressource (Artikel, Auftrag, Kunde) hat eine eigene URL
- Standardbefehle: GET (lesen), POST (anlegen), PUT/PATCH (ändern), DELETE (löschen)
- Zustandslos (stateless): jede Anfrage enthält alle nötigen Informationen
- Daten meist als JSON – heute der De-facto-Standard für ERP-Integrationen
Wie eine REST API funktioniert
REST folgt dem klassischen Frage-Antwort-Prinzip: Ein Client (etwa das ERP oder ein Shop) stellt eine Anfrage an eine URL, der Server verarbeitet sie und schickt eine Antwort zurück. Das Besondere an REST ist, wie diese Anfragen aufgebaut sind. Die URL benennt die gewünschte Ressource, und ein HTTP-Verb legt fest, was damit geschehen soll. So bedeutet ein GET auf die Adresse /orders „Gib mir alle Aufträge“, ein GET auf /orders/4711 „Gib mir Auftrag 4711“, ein POST auf /orders „Lege einen neuen Auftrag an“ und ein DELETE auf /orders/4711 „Lösche diesen Auftrag“. Diese wenigen, immer gleichen Verben machen eine REST-API schnell verständlich, weil sich das Muster über alle Ressourcen hinweg wiederholt.
Ressourcen, HTTP-Verben und Statuscodes
Jede REST-API baut auf drei Elementen auf. Erstens die Ressourcen, die als Substantive und in der Mehrzahl adressiert werden – /products, /customers, /invoices. Zweitens die HTTP-Verben GET, POST, PUT, PATCH und DELETE, die den Ressourcen die Bedeutung lesen, anlegen, ersetzen, teilweise ändern oder löschen geben. Drittens die HTTP-Statuscodes, mit denen der Server das Ergebnis zurückmeldet: 200 steht für Erfolg, 201 für „neu angelegt“, 404 für „nicht gefunden“ und 401 für „nicht authentifiziert“. Weil diese Codes im gesamten Web einheitlich sind, kann ein anrufendes System eindeutig erkennen, ob eine Übergabe geklappt hat.
Zustandslosigkeit und JSON
Ein zentrales Merkmal von REST ist die Zustandslosigkeit (stateless): Der Server merkt sich zwischen zwei Anfragen nichts über den Client. Jede Anfrage muss deshalb alle nötigen Informationen selbst mitbringen – insbesondere den Zugangsschlüssel zur Authentifizierung. Das klingt umständlich, macht REST-APIs aber robust und gut skalierbar, weil sich Anfragen beliebig auf viele Server verteilen lassen. Die eigentlichen Daten werden fast immer als JSON übertragen, einem kompakten, sowohl für Maschinen als auch für Menschen lesbaren Textformat, das JSON zum De-facto-Standard moderner Web-Schnittstellen gemacht hat.
REST API vs. SOAP, GraphQL und Webhook
REST ist der heute dominierende, aber nicht der einzige Weg, Systeme zu verbinden. Der ältere Standard SOAP (siehe soap) verpackt jede Nachricht in ein streng definiertes XML-Format und bringt umfangreiche Regeln für Sicherheit und Transaktionen mit. SOAP ist mächtig, aber schwergewichtig; man trifft es noch in etablierten Unternehmensanwendungen und bei manchen Behörden-Schnittstellen. REST gilt dagegen als schlanker, leichter zu lesen und schneller anzubinden, weshalb neuere ERP- und Shop-Systeme fast durchgängig REST anbieten.
GraphQL ist ein jüngerer Ansatz, bei dem der Client in einer einzigen Anfrage genau angibt, welche Felder er benötigt – nützlich, um Datenmengen zu bündeln und Überflüssiges zu vermeiden. Vom Webhook unterscheidet sich REST durch die Richtung: Bei REST fragt das eigene System aktiv nach Daten (Pull), während ein Webhook Ereignisse von sich aus meldet (Push). In der Praxis kombinieren viele Integrationen beides – REST für den gezielten Datenabruf, Webhooks für Echtzeit-Benachrichtigungen wie „neue Bestellung eingegangen“.
Die REST API im ERP-System
Im ERP ist die REST API die technische Drehscheibe, über die Bestellungen, Bestände, Belege und Stammdaten zwischen den Systemen wandern. Ein Cloud-ERP stellt für jedes wichtige Objekt Endpunkte bereit – für Artikel, Aufträge, Kunden, Lieferscheine und Rechnungen –, die andere Programme lesend und schreibend nutzen. So zieht das ERP neue Bestellungen aus Shop und Marktplatz, spielt aktualisierte Lagerbestände zurück und übergibt Belege strukturiert an die Buchhaltung. Diese Bestandssynchronisation über alle Kanäle hinweg ist ohne eine belastbare API praktisch nicht zu leisten.
Die Qualität einer REST-API entscheidet damit maßgeblich über die Integrationsfähigkeit eines Systems. Wichtige Kriterien bei der ERP-Auswahl sind: eine öffentlich zugängliche Dokumentation, eine vollständige Abdeckung der zentralen Objekte, verlässliche Statuscodes und ein durchdachtes Fehler-Handling. Wo Anwender nicht selbst programmieren wollen, übernehmen Konnektoren, eine Middleware oder eine iPaaS-Plattform das Ansprechen der REST-Endpunkte im Hintergrund.
Authentifizierung und Rate-Limits
Weil REST zustandslos ist, muss sich das aufrufende System bei jeder Anfrage ausweisen – meist mit einem API-Key oder einem Token nach dem OAuth-Verfahren, das man im ERP einmalig einrichtet. Zusätzlich schützen Anbieter ihre REST-APIs mit Rate-Limits, also Obergrenzen für die Zahl der Anfragen pro Zeitraum. Wer viele Datensätze synchronisiert, muss diese Grenzen beachten und Anfragen bündeln oder zeitlich verteilen – ein Punkt, den Integrationsprojekte von Beginn an einplanen sollten, um Blockaden im laufenden Betrieb zu vermeiden.
Warum REST APIs für Händler wichtig sind
Für Onlinehändler und mittelständische Unternehmen ist die REST API der Hebel, um Prozesse zu automatisieren und mit steigendem Volumen skalierbar zu halten. Ohne Schnittstelle müsste jemand Bestellungen abtippen, Bestände in jedem Kanal einzeln pflegen und Versandlabels von Hand erzeugen – mit jeder verkauften Einheit teurer und fehleranfälliger. Über REST-Endpunkte laufen diese Übergaben automatisch, in Sekunden und ohne Medienbruch.
Gerade in einer Multichannel-Landschaft mit Shop, mehreren Marktplätzen, Payment- und Versanddienstleistern ist eine offene REST-API oft das Kriterium, das über Machbarkeit und Kosten künftiger Anbindungen entscheidet. Systeme mit geschlossener oder lückenhafter API führen schnell in einen Vendor-Lock-in, weil sich Erweiterungen technisch kaum umsetzen lassen. Eine starke REST-API dagegen erlaubt es, das ERP Schritt für Schritt in eine wachsende Systemlandschaft einzubetten.
Praxisbeispiel
Beispiel: Lagerbestand über die REST-API synchron halten
Ein Händler für Outdoor-Ausrüstung verkauft über den eigenen Shop und zwei Marktplätze. Verkauft er über den Shop eine Zeltunterlage, meldet der Shop die Bestellung, und das ERP ruft sie über einen GET-Aufruf auf den Endpunkt /orders ab. Das ERP reduziert den Lagerbestand und spielt den neuen Bestand per PUT auf /products/{id} an Shop und Marktplätze zurück.
Erhält der Server dabei den Statuscode 200, weiß das ERP, dass die Aktualisierung überall angekommen ist; bei einem 429 („zu viele Anfragen“) wartet es kurz und wiederholt den Aufruf. So bleibt der Bestand über alle Kanäle synchron, und die gefürchtete Überverkaufssituation, bei der ein bereits ausverkaufter Artikel weiter angeboten wird, tritt gar nicht erst ein – ohne dass ein Mitarbeiter Zahlen von Hand pflegt.
Häufige Fragen
Passende Leistungen
Fragen zu REST API in deinem ERP-Projekt?
Wir beraten herstellerunabhängig – und setzen es auf Wunsch selbst um.