Häufig gestellte Fragen
Was unterscheidet eine REST-API von einer SOAP-Schnittstelle?
REST ist ein Architekturstil, der über das vorhandene HTTP-Protokoll arbeitet, während SOAP ein eigenständiges, streng spezifiziertes Protokoll ist, das Nachrichten verpflichtend als XML überträgt. REST-APIs nutzen meist das kompaktere und leichter lesbare Format JSON, gelten als ressourcenschonender und lassen sich gut zwischenspeichern, was sie für Web-, Mobil- und Cloud-Anwendungen attraktiv macht. SOAP bringt dagegen formale Verträge (WSDL), transaktionale Garantien und mit WS-Security ein eingebautes Sicherheitsmodell mit und ist daher in stark regulierten Umfeldern wie Finanzwesen, Behörden oder älteren Konzernlandschaften weiterhin verbreitet. In der Praxis betreiben viele ERP-Systeme beide Verfahren parallel, sodass die Wahl vom konkreten Integrationsszenario und den vorhandenen Gegenstellen abhängt.
Welche HTTP-Methoden und Statuscodes nutzt eine REST-API?
Eine REST-API adressiert jedes Geschäftsobjekt – etwa einen Kunden oder einen Auftrag – über eine eindeutige URL und wirkt mit den Standard-HTTP-Methoden darauf ein: GET liest Daten, POST legt neue Datensätze an, PUT und PATCH ändern bestehende, DELETE entfernt sie. Das Ergebnis jeder Anfrage signalisiert der Server über standardisierte Statuscodes, etwa 200 für einen erfolgreichen Abruf, 201 für einen neu angelegten Datensatz, 401 oder 403 bei fehlender Authentifizierung oder Berechtigung und 404, wenn eine Ressource nicht gefunden wurde. Diese klare und vorhersehbare Zuordnung macht REST-Schnittstellen vergleichsweise leicht verständlich und gut dokumentierbar. Weil REST zustandslos arbeitet, muss jede Anfrage alle nötigen Informationen selbst mitbringen, ohne dass der Server Sitzungsdaten zwischen den Aufrufen vorhält.
REST oder GraphQL – was passt für ERP-Integrationen besser?
REST eignet sich gut für klassische, ressourcenorientierte Integrationen, bei denen abgegrenzte Geschäftsobjekte über stabile Endpunkte gelesen und geschrieben werden, etwa die Anbindung eines Onlineshops, eines Versanddienstleisters oder eines Buchhaltungswerkzeugs. GraphQL ist dagegen ein abfrageorientierter Ansatz, bei dem der aufrufende Client in einer einzigen Anfrage exakt die benötigten Felder über mehrere Objekte hinweg anfordert, was vor allem bei datenintensiven Frontends Over- und Underfetching reduzieren kann. Viele moderne ERP-Plattformen bieten beide Varianten an, sodass sie sich ergänzen statt auszuschließen. In der Praxis hängt die genaue Ausgestaltung von Branche, Größenklasse und Customizing-Tiefe des konkreten ERP-Setups ab.
Wie wird der Zugriff auf eine ERP-REST-API abgesichert?
Der Zugriff wird typischerweise über API-Schlüssel oder Token nach dem OAuth-2.0-Standard geregelt, sodass nur berechtigte Systeme Daten abrufen oder verändern können. Als sicher gilt insbesondere der Authorization-Code-Flow, oft ergänzt um das PKCE-Verfahren für Anwendungen, die keine Geheimnisse sicher speichern können; die gesamte Kommunikation sollte ausschließlich verschlüsselt über TLS/HTTPS erfolgen. Bewährt haben sich kurzlebige Access-Tokens in Verbindung mit Refresh-Tokens sowie eng gefasste Berechtigungen (Scopes), die nur die wirklich benötigten Operationen freigeben. Zugangsdaten gehören in einen geschützten Speicher und sollten weder im Quellcode noch in öffentlichen Repositories hinterlegt werden; eine lückenlose Protokollierung der Zugriffe erleichtert zudem Audits und Fehleranalysen.
Was bedeuten Rate-Limits und HTTP 429 bei ERP-APIs?
Cloud-ERPs begrenzen die zulässige Anzahl von Anfragen pro Zeitfenster über sogenannte Rate-Limits, um die Systeme vor Überlastung zu schützen und allen anbindenden Anwendungen einen fairen Zugang zu sichern. Überschreitet eine Integration dieses Limit, antwortet die API in der Regel mit dem Statuscode 429 (Too Many Requests) und häufig mit einem Retry-After-Header, der angibt, wann ein erneuter Versuch sinnvoll ist. Als Standardstrategie gilt ein exponentielles Backoff – also schrittweise verlängerte Wartezeiten, idealerweise mit einer kleinen zufälligen Verzögerung (Jitter) –, ergänzt um Warteschlangen, die Lastspitzen abfedern. Wie viele Aufrufe tatsächlich anfallen, hängt stark vom Setup ab; je nach Transaktionsvolumen und Polling-Frequenz reicht die Größenordnung von einigen tausend bis zu mehreren hunderttausend Aufrufen pro Tag.
Wann sind Webhooks sinnvoller als das wiederholte Abfragen der REST-API?
Beim Polling fragt eine Anwendung die REST-API in festen Intervallen aktiv ab und vergleicht die Antworten, um Änderungen zu erkennen, während ein Webhook die Logik umkehrt: Das ERP-System ruft bei einem Ereignis – etwa einer neuen Bestellung oder einer Bestandsänderung – von sich aus eine hinterlegte URL der Zielanwendung auf. Webhooks liefern Aktualisierungen nahezu in Echtzeit und sparen Ressourcen, weil unnötige Leerabfragen entfallen; Polling produziert dagegen viele Anfragen, von denen oft nur ein Bruchteil tatsächlich neue Daten enthält. Webhooks eignen sich daher besonders für zeitkritische, ereignisgetriebene Prozesse, während Polling für weniger dringliche oder stapelorientierte Abläufe ausreichen kann. In der Praxis kombinieren viele Systeme beides: Webhooks melden das Ereignis, die REST-API liefert anschließend die vollständigen Detaildaten.